Hi Alex, I was waiting for your summarize in case of the preparation for release. I like your idea, cause we are exercising similar approach with Moonshine team. We are trying to have monthly release, next release just have to be better and hopefully bringing some new useful features. After 3 last month I can say that is succeeded. +1 - For the idea, let's get try to see how it's working in Royale.
As for the script and build. If your script use Maven as an creator of branches (because we know that Maven has a way to automate the process) - it may not be enough. One of the steps in case of Maven is to change current poms-version - I saw in the repo right now 0.9.1. Unfortunately it is not enough, cause many poms has not the right version, cause they are simply not in the chain. One of the example is "distribution" folder. How can we handle this in that process? You are starting script - it's doing branch and changing poms and that version is suppose to be something for the VOTE, but hey - it's not cause we have still something to correct manually. - Are we doing it on that branch ? Can we ? Many Tanks for that idea! Piotr 2018-01-08 8:57 GMT+01:00 Alex Harui <[email protected]>: > Hi, > > I think I have a script that builds all of the Maven, Ant and I think even > NPM artifacts for a Royale release. > > Instead of the Flex "Last Call" process, I would like to try a different > process and philosophy for Royale. The script takes a while to run, but > is relatively straightforward so I think we should try releasing whatever > happens to be in the develop branches more often, maybe monthly or even > more frequently than that. So there won't be any "Last Call" since that > slows down the release process while we wait for someone to finish some > code or fix small things. > > I think we should try to cut a release during the first week of every > month, and potentially more often than that if a release goes out with > blocking problems. > > As such, we want to adopt a different philosophy to voting. As > recommended by Roy Fielding, we could take the approach of "better than > the last release and not illegal". And "not illegal" means truly breaking > a law, not some policy issue. I would say we would not release something > that is in violation of the CatX handling policy though. > > So the process will be something like: in the first week of every month > (not necessarily on the 1st day of the month), someone will cut an RC and > we'll vote on it, and if we didn't break something important and aren't > breaking any laws and are handling CatX properly, we vote +1 and out it > goes. Most bugs should not hold up these releases. If something is > broken we try to fix it in a few days and hopefully out it goes then, but > most other fixes just go in the develop branch and goes in the next > release. Then towards the end of the month, we try to find a volunteer to > cut the next monthly release. If we can work together to get releases out > quickly, I will be the RM for the first couple of releases to make sure > the script holds up. > > > If we ship a release and after it goes out, something is found and we want > to release a fix right away, we will do that as well, even if that means > that the first week of the month release is only a week later. > > Any objections? Either way, the script completed building an RC, so I am > going to send out vote and discuss emails for it so people will review it > in case the script needs fixing. > > Thoughts? > -Alex > > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
