maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: [VOTE]: release maven-changes-plugin 2.6
Date Mon, 20 Jun 2011 22:15:36 GMT
Please make a new thread.

On Mon, Jun 20, 2011 at 5:51 PM, Mark Derricutt <mark@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 <struberg@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 <mark@talios.com> wrote:
>>
>> > From: Mark Derricutt <mark@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.rosenvold@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-unsubscribe@maven.apache.org>
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> > >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message