On Feb 18, 2014, at 11:47 AM, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote:
> Well all this will be for the moment is a reminder that the best tests we > have say it is releasable and that a *human* can think about cutting a > release. > > Right now it will fail to notify because there are failing integration > tests (need a 3.2.1 in central to fix the three failing tests) > > If we switch master to a 4.x line I will switch the job to follow the 3.2.x > branch. > I think that will be a few weeks as I'm in the middle of trying to punch out flipping the core to jsr330, refactor some of the resolution and get us to a place where we can make a punch list of what we're going to eject from the core. I think once everything is marked as deprecated we'll have to make some decisions about what we're going to nuke for the 4.x. I think we need to make at least one release once everything is deprecated, maybe it doesn't matter. > What I want this to do is ensure that any fixes for 3.2.x get released > quickly. > Sure, I don't disagree but again I think it's curating the issues and having something to release. The core issue is having something to release. I plan to work on the 3.2.2 list and maybe we agree to leave it that size and when it's done release it. I would rather agree that a set of issues are in a release and release it when it's done, and if it's taking too long shear off some issues and release. > The major changes will be towards 4.x, where a slower release cycle is fine. > > Given that 3.2.x should only have bug fixes how do you see this as risky? That it's releasing for releasing sake, and not trying to address the real issue of lack of movement in the core. I think if you fix some bugs it's fine for them to collect over 6 weeks. The vast majority of users are in organizations where there is no way they are going to absorb these changes. For people who are heavily involved can take CI builds and try them, otherwise a 6 weeks cadence I believe is quite good. > If anything it means that if you fix a bug in 3.2.x it will be released > quickly... 3.2.x has taken far far too long. By what measure? > High cadence when there are > changes to release is a better way. Again high cadence compared to what? > I will act as RM if nobody else steps > up during this 3 month experiment (but I would encourage other committers > to pick up the role for practice) So you're deciding I'm not the RM now after having done the last two releases? How does that work? > > - Stephen > > On Tuesday, 18 February 2014, Jason van Zyl <ja...@takari.io> wrote: > >> Sorry, but I don't think this is a good way to do releases. Honestly I >> think it's a potential recipe for disaster. >> >> As I said before, it's the lack of work being done in the core that is the >> issue. Releases aren't being made because until recently there isn't a lot >> of activity in the core. Just jumping into weekly releases is not the >> solution for having not released for 3 months. >> >> The issues need to be curated, a lot more tests need to done, and a good >> chunk of the core needs to be cleaned up before having more frequent >> releases. Having a public weekly release I don't think is going to be >> helpful. I think shooting for a release every 4-6 weeks as official >> releases is a good start, and then patch releases possibly more frequent. >> >> I'm not in favor of this and I think it's too drastic a change and isn't >> going to help. >> >> On Feb 18, 2014, at 7:26 AM, Stephen Connolly < >> stephen.alan.conno...@gmail.com <javascript:;>> wrote: >> >>> I have set up a chain of build jobs in Jenkins. >>> >>> The root of the chain is >>> https://builds.apache.org/job/maven-3.2-release-status/ >>> >>> This builds at midnight UTC every monday. >>> >>> If there are changes to the master branch of Maven since the last release >>> of Maven then that build will pass and kick off the chain. >>> >>> The next build in the chain is >>> https://builds.apache.org/job/maven-3.2-release-status-build/ >>> >>> This checks out the GIT hash provided by >>> https://builds.apache.org/job/maven-3.2-release-status/ and verifies >> that >>> it builds using the apache-release profile (and a throwaway GPG key to >> sign >>> everything - we need a GPG key to enable the profile) >>> >>> If that build succeeds then >>> https://builds.apache.org/job/maven-3.2-release-status/ gets a green >> star >>> promotion badge and >>> https://builds.apache.org/job/maven-3.2-release-status-test/ gets >> triggered. >>> >>> https://builds.apache.org/job/maven-3.2-release-status-test/ uses the >> built >>> version of Apache Maven from >>> https://builds.apache.org/job/maven-3.2-release-status-build/ and runs >> the >>> integration tests against that binary. >>> >>> If that build succeeds then >>> https://builds.apache.org/job/maven-3.2-release-status/ gets a gold star >>> promotion badge. >>> >>> After Monday, if it all works according to plan, then I will tweak the >> job >>> to send an email on success alerting us that we can cut a release of >> Maven >>> core. >>> >>> I would hope that a release manager would step forward (it may be me... >> it >>> could be anyone who feels up to cutting a release) and we would then cut >> a >>> release sometime after the mail. >>> >>> If there is no gold star on the build... then there will not be a release >>> that week... or at least I will not be pushing for one. >>> >>> If this pipeline works out ok, we can see about enhancing it with further >>> tests, e.g. windows integration tests, etc. >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> http://twitter.com/takari_io >> --------------------------------------------------------- >> >> Simplex sigillum veri. (Simplicity is the seal of truth.) >> >> >> >> >> >> >> >> >> >> > > -- > Sent from my phone Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- Three people can keep a secret provided two of them are dead. -- Benjamin Franklin
