Wow - that seems like a hell of a lot of releases having to be made... This post is probably drifting off topic but the thing that strikes me here is that this is the exact reason why maven supports version ranges - so that you don't have to make a plethora of rolling releases just because one change was made downstream.
It's no wonder a lot of version range bugs in maven never get fixed if none of the plugins or maven itself actually uses them. Of course this only solves the problem where an upstream release contains non-breaking changes for its downstream users which hopefully, for bug fixes would be more often than not. Locking down versions is good for third party dependencies, but I'm very much of the mind that ranges should be used for sibings, would certainly solve the problem of transitive release blowouts. -- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold < kristian.rosenv...@gmail.com> wrote: > > > Den 19.06.2011 23:08, skrev Gavin McDonald: > > >> I would be happy with weeks to be honest. Then again I have been used to >> being around >> slower projects that have released only every 2 or 3 years once 1 or 2 >> hundred issues have >> been gathered into a release. And the release process itself takes weeks >> of work to >> achieve. >> >> Therefore ignore me, 3 issues seems like doing a days work, then release, >> then another days >> work, then release etc ... >> >> > Given a very quick count, the apache maven project contains something like > 90 individually deployable and separately votable artifacts. Our users > upgrade these components individually according to need. Each component is > individually tested and voted for; maven is not a monolithic application and > should not be released as one. > > The downside of this componentization is that sometimes fixing a single > issue leads to the redeployment of multiple artifacts, at the moment I'm > working on 1 issue that will require the > redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere) > before it's closed in its full extent. Most likely I'll have votes for 2 of > these "soon" and I'll just let the remaining 4 roll out > together with releases planned by others. But in this context I simply > refuse to consider if a single release vote is too large or too small. > > From an agile perspective there's potential to getting a lot more issues > fixed with a single year than the kind of project you mention. I have no > specific stats but I assume we fix at least a thousand issues every year. > > Some of our projects have sufficiently good automated test coverage that I > suspect we could allow incremental .1 releases to go without a vote > entirely. I'm not sure if this is something we're even allowed to consider > ;) (Surefire would probably qualify, assuming we did some kind of formalized > "continious production" kind of review) > > I think ideally we should release every top-level component every 6 weeks > or so. But that means we'd have 1-3 votes every day ;) > > > Kristian > > > > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@maven.apache.**org<dev-unsubscr...@maven.apache.org> > For additional commands, e-mail: dev-h...@maven.apache.org > >
