Kristian can describe in more detail what he's working on, but not all changes take 8 artifact changes. In this case I think it's both that it's something that affects multiple things (rather than dependencies), and also a couple of things that have been broken down to one too separate many artifacts (like plexus-compiler, which I think is only ever used in the compiler plugin). Those sorts of exercises should actually help us understand if the right type of modularity has been applied.
- Brett On 21/06/2011, at 6:27 AM, Mark Derricutt wrote: > 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 >> >> -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
