The ant script tries to update the poms that Maven doesn't see. When Maven cuts a release branch, it tries to update the poms to the next version in the develop branch (in this case to 0.9.1-SNAPSHOT) and makes a release branch with the current version (in this case 0.9.0). The release script ignores the develop branch for now, but if there is something in there we need to fix, we can add it to the script. But the current idea is that we'll all be focused on the release branch for 72 hours, and once the release is approved, there is a target in the ant script that updates the places where Ant and Maven pick up versions and merge the release branch to develop and that should get the develop branch set up with the right versions.
We'll see how it goes. I expect there are things we need to improve in the script. The goal is to get it all to automated so we don't forget important steps or make silly errors. -Alex On 1/8/18, 12:10 AM, "Piotr Zarzycki" <[email protected]> wrote: >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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr >eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ce764362e500847 >8513cd08d5566f4161%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365099581 >97400960&sdata=1AsrVYUTzkHej7yIn0DeCVn0Z83o0mg6NZnSW76IiD0%3D&reserved=0 ><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr >eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ce764362e500847 >8513cd08d5566f4161%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365099581 >97400960&sdata=1AsrVYUTzkHej7yIn0DeCVn0Z83o0mg6NZnSW76IiD0%3D&reserved=0>*
