Mailing-List: contact continuum-users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: continuum-users@maven.apache.org
Received-SPF: pass (herse.apache.org: domain of Johan.Iskandar@ag-it.com
 designates 202.155.56.175 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Maven2 release process in Continuum
Date: Thu, 19 Jul 2007 11:53:11 +0700
Message-ID: <5A0FC4D52198F24F9CC6CFE822269363012A9752@agits-mail03.ag-it.com>
Thread-Topic: Maven2 release process in Continuum
Thread-Index: AcfJpyVptt+nf8uBS8+MX3XEDaAsAgADJhEg
From: "Johan Iskandar" <Johan.Iskandar@ag-it.com>
To: <continuum-users@maven.apache.org>

I appreciate the reply,

After yet again thinking about it(may be not hard enough :( ), we don't
need to have version numbers in the sub module poms for reason explained
below.=20
All we need is for the version number to be at the parent level pom.
And so the sub module poms are tightly coupled to the parent pom and
negating any chances of it being reused by other parent poms.
Why? If we ever need to reuse the behavior of the sub-module pom, we
need to make it a parent pom, and reuse it in a transitive dependent
way. Otherwise it would be a never ending nightmare inside a nightmare..

Though we could have sub modules inside a sub module but I don't see why
we really need that, we could just promote the deeper sub module to
become a parent module and again reuse it in a transitive dependent way.

> From: Arnaud Bailly [mailto:abailly@oqube.com]
>=20
> Yes, maven enforces an explicit declaration of version in a
> POM. AFAICT, maven does not validate a POM which does not contain a
> version number, so you cannot build it. Maven is rather agnostic about
> version numbering schemes, but understand quit well x.y.x notation
> that is used in version ranges for dependencies management.

So the build numbering scheme in maven is x.y.x, and not w.x.y.z i.e. it
doesn't differentiate between a build and a bug-fix..?

Why I think we need to differentiate between build and bug-fix is that
sometimes we want to make refactorings that doesn't necessarily fix a
certain bug (i.e. passes all currently known tests) and doesn't do any
performance enhancements (both can be signified by the y number), but
just to manage codes.
>From the user point of view the z is insignificant, but from the
developers point of view it's a big difference and that's why the z
should be there.=20

>=20
> SNAPSHOT is a special qualifier for version that says we are
> building a (surprise !) snapshot development version of a piece of
> software. Snapshots are handled differently from standard versions, in
> that:
>  - when you install/deploy a project labelled SNAPSHOT, the artifact
>  is actually deployed with a build number and the repository is
>  updated to reflect the latest snapshot
Well, if this is done so that the repository doesn't grow too big, I'm
for it though..
IMHO maven could have just ignored the z number when dealing with user
actions such as getting from/installing to repositories, by only
managing x.y.x format (cuz this is good for transitive dependencies)

But with simple additions to the config described below we could
accommodate also the w.x.y.z numbering plan
We could define whether the user/developer wants to get up to date at
the build level or just at the bug fix level..=20
-If he chooses to get up to date at the bug fix level the current
snapshot mechanism takes action ..
-If he chooses to get up to date at the build level maven will delete
all build prior to and including x.y.x.z builds and replacing it with
the new x.y.x.(z+1) in the repo, and that would still save space...

So when it comes to code changes and building the changed code maven
knows that it has to change the z number no matter what, and that would
make the automatic builds more meaningful.=20

>  - you can define different repositories for deploying/downloading
>  artifacts.
>=20
Yes this is one of the good things about maven I like.


Best regards,
Johan
Just my 2 cents