Well first off, my experience is that users are reluctant to even test -alpha- and -beta- releases and consequently there is next to zero chance of them testing an RC.
Additionally with fast cadence releases the RC will most likely get released anyway... if they have an issue with that *reproducible* build they can report it and get the fix in the next RC (which won't be long as this is a fast cadence release project) When I was integrating the Jenkins Credentials support into the Jenkins Subversion plugin, we cut a functionally complete release with a -beta- label and said: "Look this is ready to go, but we need testing of the credentials migration from real users, can you please test it?" 3 months later we had zero feedback from users. We've had alpha and RC *releases* of Maven in the past, and we only get feedback from users when we cut an actual release. Users empirically, at least the ones I have seen, do not want to try anything with an "RC" or "alpha" or "beta" in the version number. They want a solid piece of ground upon which they have a chance of building some stability... only if they *really* need a bleeding edge fix/feature will they venture to try the RC/alpha/beta Faster cadence enables more user involvement by getting releases that users are willing to consume into their hands faster... Does that mean it is right for every project? Hell no... it is a trade-off... putting out weekly releases raises other problems... "I haven't upgraded Jenkins in 4 weeks, what version of Jenkins should I upgrade to?" is the most obvious problem... In other words, when releases are cut every week, users now face the problem as to which version they use. Projects need to address that problem with things like usage statistics, version rating, recommended versions, etc. A slower release cadence allows for higher quality... but if the version you need also has a bug in an unrelated area, you may have no version you can choose to use... the fast release cadence gives the user a better chance that the feature was added in one version and the bug introduced in a later version (and if vice-versa, they can probably back out the bug and back-port the feature a lot more easily if they want to roll their own build) As I said at the beginning, I have been working with Jenkins since it's 2nd or 3rd public non-sun release... the rapid release cycle worked wonders for my engagement... even if at first the sometimes multiple releases per day caused issues... the switch to weekly releases was good for Jenkins and I think weekly releases have encouraged the Jenkins user community rather than hindered it... especially when I compare with the "name-thief fork" and it's significantly slower cadence. On 10 February 2014 11:37, Joseph Schaefer <joe_schae...@yahoo.com> wrote: > I can see why cutting the time window might lead > to a faster release cadence, but what I don't get > is why this is a desirable goal. Generally > speaking, we try to encourage users to get involved > in development, ostensibly by vetting release candidates > as a zeroth order thing they can do to help the project. > > The net effect of reducing opportunities for user participation > in the release process would lead me to guess that the opposite > flow will happen- that surplussed users will stop following dev > and go back to the user lists. If I'm right, then why > is this a good and desirable effect for an Apache project? > > > > On Feb 10, 2014, at 3:30 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > On Monday, 10 February 2014, Upayavira <u...@odoko.co.uk> wrote: > > > >> > >> > >> On Sun, Feb 9, 2014, at 06:40 AM, Marvin Humphrey wrote: > >>> On Sat, Feb 8, 2014 at 3:26 PM, Stephen Connolly > >>> <stephen.alan.conno...@gmail.com <javascript:;>> wrote: > >>>> 72h for a vote is not a hard and fast rule (you just need a good > >> reason for > >>>> why you are going shorter and from what I have seen, the board would > >>>> probably be ok as long as protections are put in place to safeguard > the > >>>> community) > >>> > >>> By now, I think that we've demonstrated in this thread that scheduled > >>> votes with a small window (12-24 hours) are practical. > >> > >> Have we? > >> > >> I don't believe anyone has expressed the real justification for a 72hr > >> window, which is to enable the vote to be *inclusive*. That is, > >> inclusive of people who don't live in the same timezone, and who perhaps > >> don't work on the codebase full time. > >> > >> Yes, a 12hr window might make it possible for everyone to have at least > >> 4 waking hours in that window, but what if that is your 4hrs of taking > >> your kids to school, or cooking dinner for the family. Or if they > >> contribute in their spare time, and that 4hrs is whilst they are at > >> work. If the project chooses that particular 12hr window as a fixed > >> thing, it effectively excludes you from the vote. > > > > > > But this is a *scheduled* vote... If you know that it is something you > > *want* to have a chance to vote on, you have sufficient time to ensure > the > > vote is extended in order for you tiger your say. > > > > IMHO 72h is needed *when you don't know that there will be a vote*... > This > > would be a different case... Though I ack that I had only thought this > and > > not articulated it prior > > > > > >> I am in no way attempting to argue that 72hrs votes is the only way to > >> achieve this particular aim, but I do not consider this issue as > >> addressed in any way in this thread yet. So: > >> > >> If we are going to shorten release vote durations, how do we ensure > >> inclusivity, both of current, and potential future contributors, > >> irrespective of timezone, work pattern, etc? > >> > >> Upayavira > >> > > > > > > -- > > Sent from my phone > >
