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. What I want this to do is ensure that any fixes for 3.2.x get released quickly. 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? 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. High cadence when there are changes to release is a better way. 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) - 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
