Please make a new thread. On Mon, Jun 20, 2011 at 5:51 PM, Mark Derricutt <m...@talios.com> wrote: > (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 >> >> >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
