On 10 Sep 07, at 5:04 PM 10 Sep 07, Brett Porter wrote:
On 11/09/2007, at 2:59 AM, Jason van Zyl wrote:
Hi,
For 2.1 I have been trying to lock down all the versions so that
the dependencies are stable. When I need to fix something in
classworlds, plexus, or modello, I just make the fix, install,
test and if everything works deploy it and lock down the versions
in the build and continue.
I would like to do the same with maven-artifact and get a little
more agile, and not force people to use a snapshot. For alphas I
think it would be acceptable to get 3 +1s from PMC members and
then push it out. For anything in beta or beyond it's the standard
procedure, but pushing out an alpha or incremental release just
takes too long and it is in those times of flux that the bugs in
the snapshot mechanism bite you.
I certainly applaud more frequent releases, but I don't think this
rapid an approach is going to be helpful.
It is helpful, it means you're not subject to snapshot problems. Not
using the snapshots requires more rigour, and doing more releases
just shakes out the whole process.
While it's probably not the case for m-artifact, more generally you
start to see too many different versions of things that aren't
compatible floating around and causing problems (c.f. plexus). At
least with snapshots people pretty quickly converge to the same
binary.
If we had a decent Clirr setup that would not be the case, in fact it
would be very hard to do.
I think the problems are most often because the latest snapshot is
not built/published. I can automate that from Continuum right now
if we want that, so I don't think that's an issue.
It doesn't help with the current problems with snapshots, but you can
try (the -nsu option, the failing test, numerous complaints of the
wrong snapshot coming own ...). Start publishing them, it certainly
can't hurt but a release is certainty.
I think this will also force us to start changing things to what
they are. Doxia for example should probably be a beta, not an alpha.
Making alpha releases easier than betas will *discourage* them
being changed to what they are.
You have no evidence for that. I think building up momentum with a
series of alphas will help produce a beta. And it gives people
experience with releasing more frequently.
I want to be able to fix things in maven-artifact as using
SNAPSHOTs is not good for external dependencies, but I don't want
to be grounded for 3 days while I wait to release maven-artifact
in order to pick up a stable set of changes.
If components/trunk needs to track changes in m-artifact that
closely, something is wrong.
It was just decoupled, there's nothing wrong. It's not like it's a
completely stable project that's lived on its own for a year. It's
still totally coupled to MavenMetadataSource to even be useful so
they have hardly approached the state of being decouple. That
statement is erroneous. What other driver do we have for the library?
Who else uses maven-artifact? The answer is no one.
If I were to take an extreme opposite viewpoint (and I realise it's
not practical, but it serves as an example) - since we're
committing to keeping the old APIs working, everything could really
be done in m-artifact first, and Maven flipped at the end.
The point is to fix the serious flaws in Maven which are the serious
flaws in the artifact mechanism. So that wouldn't make much sense. If
it were a stable library that had lived on its and had many clients
not us it would be a valid argument. The fact is it's barely
decoupled and still only functional when combined with Maven. It's
useless otherwise currently.
I would like to see m-artifact built to work on it's own, so
anything that nudges it towards that is a good thing.
We can use timestamps too I suppose, but then what's the
difference really. I just want to get the 2.1 release out faster.
Sorry, I just don't see anything that indicates this will help the
release get out faster.
Making it easier for others to build, the general stability of using
releases.
I think it's really about getting a better balance - release more
often than we do now, but still spend the time to consider what
that release should mean, and ensure it retains a level of compat,
stability and testing that makes it a safe upgrade.
Cheers,
Brett
--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
