Technically I'd get away with updating 2-3 artifacts, but I'd end up
writing a cookbook on how to add a crapload of dependencies to the
plugins in question and answering on the mailing list and irc, and in
the end we'd have a ton of poms lying around with 3 overridden
dependencies in 4-5 plugins. So as as service to our end users I think
the fair thing is to release new versions. Now given that we manage to
maintain an "average" release schedule of 4-8 weeks, I would probably
just ignore releasing the plugin, but currently I think our release
schedules are driven by itches like mine. So I suppose we *could* solve
this by just assigning regular releases to committers. Personally I
don't /mind/ taking responsibility for releasing 2-3 plugins every 6-8
weeks if I knew someone else did the others.
I think version ranges for plugins are fairly dangerous because you'll
be removing the determinism in the build. Even though you lock down
plugin versions, you risk getting a new version of maven-shared-foobar
any day. I just need introduce *1* platform specific bug in
maven-shared-foobar to paralyze the entire community of "windows" users.
I've seen this happen in other projects that (for instance) have *no*
committers working on windows (yes, it's becoming fairly commonplace).
Kristian
Den 21.06.2011 02:38, skrev Brett Porter:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
