I am all for maintaining stability of branches, and the trunk, as everyone benefits from it. But I do not think this means we should limit bug fixing in the branches to only critical issues. As Pig gets more users we have more and more people on older branches who will want fixes for bugs without dealing with bigger version changes. So I am not in favor of limiting checkins to branches to P1 issues.
What if we maintain stability on the branches by quickly reverting any patches that break the build, the unit tests, or the e2e tests? This allows us to move forward with bug fix versions, it allows those who depend on branch stability (which I suspect is everyone in the distribution business plus everyone rolling their own Pig), and it should promote developer responsibility (no one likes having their patches reverted). Alan. On Nov 2, 2012, at 3:58 PM, Olga Natkovich wrote: > Hi guys, > > Mid next year, we agreed on a release process documented in this thread: > http://www.mail-archive.com/dev@pig.apache.org/msg04172.html. > > Since then, we have not really followed either of its two rules: > > (1) Frequent (every 3 month releases) > (2) Branch stability (only P1 issues on the branch). > > So I wanted to revisit our release procedure to make sure we have one that we > can actually follow. > > For us at Yahoo, branch stability is very important since we release all the > patches directly from the branch. If we can't rely on the fact that only > critical fixes go in, we will need to resort to git branches that will make > the whole process very comberson because we now need to hand pick patches > from the apache branch and port them onto our private branch. I would imaging > that others using Pig in production would have similar issues. > > Olga > > > Olga
