continuum-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse McConnell" <jesse.mcconn...@gmail.com>
Subject Re: Maven2 release process in Continuum
Date Thu, 19 Jul 2007 06:57:56 GMT
ok, I am a bit confused by what your actually asking here...

but there is no reason in the world you can't use w.x.y.z versioning...

On 7/19/07, Johan Iskandar <Johan.Iskandar@ag-it.com> wrote:
> 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.
> 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]
> >
> > 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.
>
> >
> > 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..
> -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.
>
> >  - you can define different repositories for deploying/downloading
> >  artifacts.
> >
> Yes this is one of the good things about maven I like.
>
>
> Best regards,
> Johan
> Just my 2 cents
>
>
>


-- 
jesse mcconnell
jesse.mcconnell@gmail.com

Mime
View raw message