To be clear, I am not sure if Maven wants such a rapid release cycle... after all we have been supposed to release 3.2.0 since Oct 1st 2013... and it's still not ready... The other way of looking at it is that if we did have a 1 release every 7 days we'd probably have 3.2.0 out already!
There are other Apache projects that for sure would like to have the 7 day cadence, so this is a question that has general relevance at Apache On 7 February 2014 11:44, Bruno P. Kinoshita <brunodepau...@yahoo.com.br>wrote: > Hi Stephen, @all > > I'm not involved in the Maven development, but I enjoy writing plug-ins > for > Jenkins. > > From a plug-in developer point of view, whenever a developer needs a > change > in the Jenkins core, s/he knows that once there is a fix/pull request > for his issue, it will get released probably within one or two weeks after > it gets merged into master branch. > > So I imagine that developers of plug-ins for Maven could benefit of having > shorter release cycles too. > > I also see lots of bugs being filed in Jenkins JIRA once a release is > out. Although it is a good practice to use the LTS, I think many users > install the latest version. This helps to find bugs before they are > released in the LTS version (sometimes it's hard to write tests for > all envs + variables). > > So my +1 (probably not binding :) > > Bruno P. Kinoshita > http://kinoshita.eti.br > http://tupilabs.com > > >________________________________ > > From: Stephen Connolly <stephen.alan.conno...@gmail.com> > >To: dev@community.apache.org > >Sent: Friday, February 7, 2014 9:14 AM > >Subject: Re: How can we support a faster release cadence? > > > > > >On 7 February 2014 11:02, Stephen Connolly > ><stephen.alan.conno...@gmail.com>wrote: > > > >> One of the projects I am involved with is the Jenkins project. At > Jenkins > >> we cut a release of Jenkins every wednesday... assuming the test all > pass... > >> Not every release is as stable as people might desire (the tests don't > >> catch everything), hence there is the LTS release line, but none the > less, > >> there is a major release every 7 days... and if you look at the usage > stats > >> (e.g. http://stats.jenkins-ci.org/jenkins-stats/svg/201312-jenkins.svg) > >> most users actually stick fairly close to the latest release. > >> > >> I have found that this 7 day release cadence can be really helpful for > >> some code bases. > >> > >> When I started to think about could we follow this model for the Maven > >> project as we move towards Maven 4.0, there is one thing that gets in > the > >> way... namely release votes. > >> > >> The standard answer is that we could publish snapshots... but those are > >> not indented for use by users... and where the cadence can help is that > >> these things can be picked up by users. > >> > >> So what is it that gets in the way with release votes: > >> > >> * The 72h "soft" requirement for vote duration > >> > >> * The actions that a PMC member is required to perform before they can > >> vote. See http://www.apache.org/dev/release which states: > >> > >> > Before voting +1 PMC members are required to download the signed > >> source code package, compile it as provided, and test the resulting > >> executable on their own platform, along with also verifying that the > >> package meets the requirements of the ASF policy on releases. > >> > >> So how exactly do these things get in the way? > >> > >> Well as I see it the 72h vote duration isn't necessarily a big deal... > we > >> need some duration of notice about what is going into the release, there > >> will always be people who feel the duration is either too short or two > >> long... but with a 7 day cadence and maybe a few hours before the > release > >> manager closes out the vote and then you wait for the release to > finished > >> syncing to the mirrors and then the release manager gets a chance to > verify > >> that the release has synced to at least one mirror... you could easily > lose > >> half a day's duration in that process... > >> > > > >My bad... looking at http://www.apache.org/dev/release I missed > > > >> Please ensure that you wait at least 24 hours after uploading a new > >release before updating the project download page and sending the > >announcement email(s). > > > >So that basically means it could be 4.5 days after the release is cut > >before it is announced as available to users... wait an average of 12h for > >a user to download it, add another 12h for them to identify the bug/issue > >and report it with a test case... That leaves maybe a 1.5 day window for > >the committers to fix the issue the user has... > > > > > >> oh look the release is out 3.5 days after it was cut... and we're > cutting > >> another one in 3.5 days... it is likely we will not get much meaningful > >> feedback from users in the remaining 3.5 days... so essentially you end > up > >> with a ping-pong of break... skip... fix since if a bleeding edge user > >> finds an issue in 4.0.56 we will have cut 4.0.57 by the time they > report it > >> to us and the fix ends up in 4.0.58... with a shorter vote duration, say > >> 12h, the bleeding edge user reports the issue, we fix and the next > release > >> is the one they can use. > >> > > > >The point of a fast cadence is that users know if they have an issue and > >report it reasonably early enough, they will get the fix in the next > >release... if we lose 4.5 days between the cutting of the RC and the [ANN] > >email we can actually harm the community, at least from my experience with > >the Jenkins project with respect to user engagement. > > > > > > > >> > >> In the context of a fast cadence, where every committer in the community > >> knows there will be a release on wednesday cut from the last revision > that > >> passed all the tests on the CI system unless there have been no commits > >> since the last release that meet that criteria, do we need to wait the > full > >> 72h for a vote? Would 12h be sufficient (assuming the 3 PMC +1's get > cast > >> during those 12h... and if not, well just extend until enough votes are > >> cast) > >> > >> I think this is different use case from my understanding of the concerns > >> that drove the 72h vote duration convention, as this would not be 3 PMC > >> members who all work for the same company and are in the same location > >> conspiring to drive their changes into the release... everything would > be > >> happening in the open and a 12h window mid-week should allow at least > 4h of > >> waking time in any TZ. > >> > >> So the second issue is what a PMC member is required to do before > voting... > >> > >> As a PMC member you are required to > >> > >> 1. Download the source code package > >> 2. Compile it as provided > >> 3. Test the resulting executable on your own platform > >> 4. Verify that the package meets the requirements of the ASF policy on > >> releases > >> > >> Do we really have to personally do all that *by hand*? > >> > >> Why can we not have a trusted build server hosted on Apache hardware do > >> the download of the source package, compile it as provided and run the > >> automated acceptance tests (on a range of platforms), the RAT tooling > and > >> perhaps verify that the source code package matches what is in source > >> control? The trusted build server could then report the results to the > >> project mailing list and then the PMC members just need to confirm the > >> build server said OK, review the commits between the last time they > looked > >> at the commits and the tag (which they know matches what is in the > source > >> bundle) and then vote +1? > >> > >> The PMC members are supposed to be keeping an eye on the commits anyway, > >> so that shouldn't be too onerous, and the release manager could even > >> provide a link to the build server confirmation build in the VOTE email. > >> > >> I would appreciate any people's thoughts on the above. > >> > >> -Stephen > >> > >> P.S. > >> * Speaking in my personal capacity as a member of the ASF. > >> * I am not saying that Maven will move to such a model, or even wants to > >> move to such a model... more that I was thinking about the issues that > >> might prevent us if we so desired... I know other projects at Apache are > >> interested in fast release cadence however, so getting this topic > discussed > >> in the open is no bad thing IMHO > >> > >> > > > > > > >
