+1. Very good reasoning, Stephen. Let's just try and accelerate at least just a bit to see how it works. If it's difficult to handle, then just brake a bit and that's all. >From an external PoV I can only think of it being beneficial to show the project is up and running.
Thanks Jason. 2013/7/28 Stephen Connolly <[email protected]> > On Sunday, 28 July 2013, Robert Scholte wrote: > > > Hi, > > > > Personally I'm not a huge fan of the release-model as done by Jenkins, > > meaning releasing once or twice a week with only a few fixes. > > > I am a really big fan of this model... But it won't work the same for > Maven... > > Where the model falls down is when you want to evolve an API, you either > have to hold back on a feature branch, rebasing all the time, or push it > out piecemeal and have to maintain backwards compat for intermediary > iterations. > > I would propose that every (1 week or 2 weeks... Lets pick one of these) we > evaluate the changes to all active release lines... If there are confirmed > bug fixes in the line, pull the trigger and get the release done. > > For 3.2, until it is ready to become a release line, I don't see value in > cutting alphas... Anyone interested *should* be able to build their own > -SNAPSHOT and we don't get uptake on alphas anyway > > > > As a user I'm not going to update for every new release, it most have > real > > value before I upgrade. > > > As a user, if a bug is blocking me I want the official release build now. > > > > As both developer and user it's much more easier to recognize issues as > > part of a specific version, if the number of releases stays small enough. > > > Bull. Easier to try one up or one down and see the issue present/gone and > now we have a smaller commit range to evaluate. > > > > I'd prefer to gather more fixes per release and go for a 6-8 week (or 4-6 > > week) release cycle. > > > And that needs a release manager who is happy to run with the required > cadence. > > The release manager decides when to release... If they are causing too much > work reviewing releases, they will fail to get enough PMC votes and this > will self regulate. > > > > IIRC that was also the original intention with M3. > > > > > How did that work out for us? Lets try faster, as a plan of 6-8 weeks ended > up as > 1 year > > A plan of 1-2 weeks on that basis will probably end up at about every 8-10 > weeks ;-) > > Robert > > > > Op Sun, 28 Jul 2013 18:36:32 +0200 schreef Jason van Zyl <[email protected] > >: > > > > On Jul 28, 2013, at 12:25 PM, Hervé BOUTEMY <[email protected]> > >> wrote: > >> > >> I'd like to work on cd tonight > >>> > >>> so if you wait for tomorrow... > >>> > >>> > >> I don't really want to wait, why can't that just go in next week? You > >> don't know how long it will take and I think we should just start > releasing > >> what we have. > >> > >> notice there are 2 ITs failing on ASF's Jenkins because of a failure to > >>> find > >>> artifacts that are available AFAIK in the local repo: I suppose I'm > >>> missing > >>> something trivial in the configuration > >>> Can you help me on this, please? > >>> > >> > >> The ITs need to work, I till take a look at report back. > >> > >> > >>> Regards, > >>> > >>> Hervé > >>> > >>> Le dimanche 28 juillet 2013 12:08:35 Jason van Zyl a écrit : > >>> > >>>> I'd like to release Maven 3.1.1 and try to get the cadence revived for > >>>> minor > >>>> version releases by trying to release minor versions as frequently as > >>>> there > >>>> are fixes to make available. > >>>> > >>>> Just a couple simple fixes: > >>>> > >>>> [MNG-5499] maven-aether-provider leaks Sisu Plexus and ObjectWeb > classes > >>>> onto the classpath when they are not required [MNG-5495] API > >>>> incompatibility causes Swagger Maven Plugin (and others) to fail under > >>>> Maven 3.1.0 > >>>> > >>>> But helps consumers of the Maven Aether Provider and plugin issues > >>>> caused by > >>>> incompatibilities with the converters. There are lots of other things > to > >>>> fix, but as they become available they can be released. If possible > I'd > >>>> just like to start releasing any fixes we have on a weekly basis. > >>>> > >>>> Any objections? > >>>> > >>>> Thanks, > >>>> > >>>> Jason > >>>> > >>>> ------------------------------**---------------------------- > >>>> Jason van Zyl > >>>> Founder, Apache Maven > >>>> http://twitter.com/jvanzyl > >>>> ------------------------------**--------------------------- > >>>> > >>>> A man enjoys his work when he understands the whole and when he > >>>> is responsible for the quality of the whole > >>>> > >>>> -- Christopher Alexander, A Pattern Language > >>>> > >>> > >>> ------------------------------**------------------------------** > >>> --------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > >> Thanks, > >> > >> Jason > >> > >> ------------------------------**---------------------------- > >> Jason van Zyl > >> Founder, Apache Maven > >> http://twitter.com/jvanzyl > >> ------------------------------**--------------------------- > >> > >> People develop abstractions by generalizing from concrete examples. > >> Every attempt to determine the correct abstraction on paper without > >> actually developing a running system is doomed to failure. No one > >> is that smart. A framework is a resuable design, so you develop it by > >> looking at the things it is supposed to be a design of. The more > examples > >> you look at, the more general your framework will be. > >> > >> -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks > >> > >> > >> > >> > >> > >> > > ------------------------------**------------------------------**--------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > -- > Sent from my phone > -- Baptiste <Batmat> MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
