On Tue, Nov 13, 2012 at 4:27 AM, Rohit Yadav <rohit.ya...@citrix.com> wrote: > I've only one concern, if we go for a 4.0.1 bugfix release, since there are a > lot of changes in build system and packaging on master, simply cherry picking > may not work. > I would like to suggest that we drive all our engineering efforts on master > (release wise, build system, esp. pkging are blockers on master), switching > between 4.0 and master may confuse people, I've seen some of my colleagues > now becoming comfortable with maven, yes the build system, so let's not go > back to ant. Maybe we can cut out a 4.0.1 release based on master since there > has not been any major feature or backward compatibility breaking change on > master. Flames, thoughts? >
That's the 'problem' with having to support releases, you just can't abandon them. It is a non-trivial amount of work, and there may indeed be patches that can't simply be cherry-picked but if we 'abandon' the 4.0.x branch I fear we send the wrong message. We know the state of the 4.0.0 branch compared to 4.0.0 release, but master is a completely different animal at this point, particularly with regards to packaging - and that raises the QA bar IMO, because it isn't just whether the code works, but if it works in its new deployable form. This overhead also means we should be very conservative about what we actually try fixing in 4.0.x - there are some bugs that are bad enough, to warrant being handled in 4.0.1 but that number is pretty small at this point.
