(Other) Mark, I'm not sure I see the connection here? Lukas had made comment that making one release would trigger cascading releases, which I assume is because downstream plugins have fixed version number dependencies.
However if those dependencies were [1.0,2.0) then they would use the most recent automatically without having to rerelease everything. -- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree On Tue, Jun 21, 2011 at 8:39 AM, Mark Struberg <strub...@yahoo.de> wrote: > Mark, > > maybe this is not so obvious, but Maven internally has ClassLoader > isolation between plugins. This is comparable to a servlet container where 1 > webapp only can see its own classes. This way it is no problem that there > are more versions of a plugin (or any other dependency) being used in the > same maven build. > > LieGrue, > strub > > --- On Mon, 6/20/11, Mark Derricutt <m...@talios.com> wrote: > > > From: Mark Derricutt <m...@talios.com> > > Subject: Re: [VOTE]: release maven-changes-plugin 2.6 > > To: "Maven Developers List" <dev@maven.apache.org> > > Date: Monday, June 20, 2011, 8:27 PM > > 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 > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
