You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Vincent Massol <vm...@pivolis.com> on 2003/11/20 10:05:18 UTC
Version 1.0, 1.1, HEAD and BRANCHES (was 1.0 RE: [VOTE] Make groupId mandatory for POM version 4?)
I guess it all depends on the question of whether we wish to link POM
versions to Maven releases. I think, I'm being swayed and I agree it's
cleaner to link them....
<thinking some more>
Ok, I think I've realized what the problem is: We are developing 1.0-RC1
on HEAD. This is the main problem. Normally here's how I would expect
development to work:
- HEAD always contains latest development for the *next* release (that
would be 1.1-SNAPSHOT for us)
- Once a beta is released, CVS is branched (that would be
MAVEN_1_0_BRANCH for us) and bug fixing happens on that branch while
development for the next release continues on HEAD. For us the beta
period has lasted too long but we could say that RC goes into a branch.
Should this happen (i.e. move RC1 to a branch and start 1.1 dev on HEAD)
then I'm happy to roll back all my changes related to POM4 and commit
them on HEAD (1.1-SNAPSHOT).
What do you say?
Thanks
-Vincent
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@pivolis.com]
> Sent: 20 November 2003 09:38
> To: 'Maven Developers List'
> Subject: RE: [VOTE] Make groupId mandatory for POM version 4?
>
> Hi dIon,
>
> > -----Original Message-----
> > From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> > Sent: 20 November 2003 09:28
> > To: Maven Developers List
> > Subject: RE: [VOTE] Make groupId mandatory for POM version 4?
> >
> > I *really* don't wont a POM change between an RC and a 1.0 release.
>
> It's not a POM change as nothing is changed from POM3 and we're not
> telling users to switch to POM4. Ok, let me explain the little that
was
> changed and you'll be able to comment on it:
>
> 1/ modified marshaller/unmarshaller to support top level <type>
element.
> That doesn't change any existing code
>
> 2/ modified marshaller/unmarshaller to support top level <version>
> element (in addition to <currentVersion>, not touched)
>
> 3/ modified marshaller/unmarshaller to support top level <artifactId>
> element (in addition to <id>, not touched)
>
> 4/ renamed maven-project.xsd to maven-project-3.xsd. This is to allow
> easy migration to a new POM
>
> 5/ created a new maven-project-4.xsd (for POM4).
>
> 6/ modified pom:validate goal to check for valid POM versions. It
> currently checks for either POM3 or POM4
>
> 7/ modified pom:validate goal to support different POM versions. It
does
> this by validation maven-project-${pom.pomVersion}.xsd
>
> That's all I did and I don't believe it can cause any trouble. What I
> would like to continue doing is:
>
> 8/ modify the marshaller/unmarshaller to support top level
> <compatibilities> elements. BTW, this was discussed on IRC and on the
> maven list I believe. I'll reopen the discussion before doing anything
> as you were not here at that time and maybe not enough persons have
> commented on it (AFAIR, Jason, Bob and me were ok on it).
>
> 9/ modify the multichanges plugin to add href links to the generated
> report (for POM4 only as it requires info from <type>).
>
> Could you please answer telling me if you think some of these steps
> should be rolled back and whether you believe it is ok for me to
> continue with 8/ and 9/ (provided we get an agreement from you on 8/)?
>
> Thanks
> -Vincent
>
> > --
> > dIon Gillard, Multitask Consulting
> > Blog: http://blogs.codehaus.org/people/dion/
> >
> >
> >
> > "Vincent Massol" <vm...@pivolis.com> wrote on 20/11/2003 07:04:25
> PM:
> >
> > > Actually, that's not exactly true. I have already put POM v4 stuff
> in
> > > CVS. However, it's completely transparent to POM3 users and I do
> agree
> > > that we must provide 100% POM3 compatibility for 1.0.
> > >
> > > Here's what I would like to do. Please provide input on whether
you
> > > think it's acceptable or not.
> > >
> > > 1/ Continue to add the <compatibilities> stuff in POM4's XSD file
> and in
> > > the marshaller/unmarshaller
> > >
> > > 2/ All plugins should stay compatible with POM3 for now. In the
> > > multichanges plugin, I'd like to add a feature: create an href
link
> to
> > > the plugin distributable files. I will need to use the new <type>
> > > element, available only in POM4. Thus the multichanges plugin will
> not
> > > have links when projects are using POM3 and will have links if
> projects
> > > are using POM4. In this manner it remains completely compatible
with
> > > POM3 while providing additional features for POM4. This should be
a
> rule
> > > that all plugins need to be friendly with POM3.
> > >
> > > 3/ The website xdoc reference guide needs to be revisited to
explain
> > > POM3/POM4 and explain the differences. We have 2 options:
> > > - one menu item for POM3 and another one for POM4
> > > - a single page for both POMs but explaining the differences
where
> the
> > > 2 POMs diverge.
> > > I think I'd prefer the first option. It should clearly be stated
> that
> > > POM3 is currently the officially released POM and that Maven 1.0
is
> 100%
> > > compatible with it.
> > >
> > > 4/ I've created a wiki page to describe the differences between
> POM3's
> > > XSD and POM4's XSD: http://wiki.codehaus.org/maven/Pom4vsPom3
> > >
> > > Comments?
> > >
> > > Thanks
> > > -Vincent
> > >
> > > > -----Original Message-----
> > > > From: Brett Porter [mailto:bporter@f2network.com.au]
> > > > Sent: 18 November 2003 22:55
> > > > To: 'Maven Developers List'
> > > > Subject: RE: [VOTE] Make groupId mandatory for POM version 4?
> > > >
> > > > My understanding is 1.1, as to my knowledge there has been no
> handling
> > > put
> > > > into CVS yet.
> > > >
> > > > We must retain full v3 compatibility for 1.0 at the very least.
> > > >
> > > > Cheers,
> > > > Brett
> > > >
> > > > > -----Original Message-----
> > > > > From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> > > > > Sent: Wednesday, 19 November 2003 3:18 AM
> > > > > To: Maven Developers List
> > > > > Subject: Re: [VOTE] Make groupId mandatory for POM version 4?
> > > > >
> > > > >
> > > > > Is POM v4 a 1.0, 1.1, or 2.x change?
> > > > > --
> > > > > dIon Gillard, Multitask Consulting
> > > > > Blog: http://blogs.codehaus.org/people/dion/
> > > > >
> > > > >
> > > > >
> > > > > Jason van Zyl <jv...@maven.org> wrote on 14/11/2003 08:05:30
> AM:
> > > > >
> > > > > > On Thu, 2003-11-13 at 15:57, Vincent Massol wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I'd like to make <groupId> a mandatory element in POM
> version 4.
> > > > > > > What
> > > > > do
> > > > > > > you think? The reason is that I don't what the default can
> be if
> > > > > > > it's not specified and if we want to have plugins that
> > > > > start using
> > > > > > > the id/groupId/type elements, there must be a groupId
> defined.
> > > > > > >
> > > > > > > Here's my +1
> > > > > >
> > > > > > +1
> > > > > >
> > > > > > > Thanks
> > > > > > > -Vincent
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> --------------------------------------------------------------------
> > > > > > > -
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > --
> > > > > > jvz.
> > > > > >
> > > > > > Jason van Zyl
> > > > > > jason@zenplex.com
> > > > > > http://tambora.zenplex.org
> > > > > >
> > > > > > In short, man creates for himself a new religion of a
rational
> and
> > > > > > technical order to justify his work and to be justified in
it.
> > > > > >
> > > > > > -- Jacques Ellul, The Technological Society
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > > 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
> > > > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > 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
>
>
>
> ---------------------------------------------------------------------
> 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
RE: Version 1.0, 1.1, HEAD and BRANCHES (was 1.0 RE: [VOTE] Make
groupId mandatory for POM version 4?)
Posted by Jason van Zyl <jv...@maven.org>.
On Thu, 2003-11-20 at 11:19, Vincent Massol wrote:
> Why? What are other's experience? AFAIK, there's no better way,
> especially for projects like Maven where it takes several months between
> a RC and a release.
>
I don't think what we currently do is really the best. I think your
notion of having a branch where work is done for the impending release
probably makes more sense. Leaving HEAD for the most current development
processes target for subsequent releases also makes more sense to me as
well.
But I agree with Dion that you cannot start making changes or additions
to HEAD which is currently slated for 1.0 until we figure out what we're
going to do wrt what branches will be for what versions and what HEAD
actually represents to us.
Vincent, I'm all for what you suggest as it means we can actually
develop easier in parallel but some simple naming schemes and a small
paragraph describing how we move from branch to branch would be nice.
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Version 1.0, 1.1, HEAD and BRANCHES (was 1.0 RE: [VOTE] Make groupId
mandatory for POM version 4?)
Posted by di...@multitask.com.au.
"Vincent Massol" <vm...@pivolis.com> wrote on 21/11/2003 03:19:46 AM:
> > The next release for us is 1.0, not 1.1-SNAPSHOT. We haven't had a 1.0
> > yet.
>
> Yes, of course. But are you saying nobody is allowed to develop for the
> following release (1.1) before 1.0 is released? As it is very bad form
> to add new stuff to a RC release (only bugfixes are allowed), where do
> you suggest people commit new stuff? Somewhere other than HEAD? That
> looks really weird as the latest stuff is expected to be on HEAD...
If you want to work on 1.1 now, I'm happy to create a 1_0 branch and work
in there.
Is this really what you want? There are lots of features scheduled for 1.0
already in Jira (see
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10030&fixfor=10211
) , but I don't remember POMv4 being one of them.
It seems that up until now, 1.1 has had noone working on it, and this is
our opportunity to start that work.
[snip]
> Where do you commit new stuff that happens between the phase where you
> have RC on HEAD?
You theoretically don't have that long between RC and release.
> Why? What are other's experience? AFAIK, there's no better way,
> especially for projects like Maven where it takes several months between
> a RC and a release.
Agreed. The time between RCs and 1.0 means that if someone wants to start
work on 1.1 or even 2.0 for that matter, a branch is the best way.
My personal priority is a stable 1.0 release. I've been working for months
to get to that point and don't want to stop now.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Version 1.0, 1.1, HEAD and BRANCHES (was 1.0 RE: [VOTE] Make groupId mandatory for POM version 4?)
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> Sent: 20 November 2003 15:41
> To: Maven Developers List
> Subject: Re: Version 1.0, 1.1, HEAD and BRANCHES (was 1.0 RE: [VOTE]
Make
> groupId mandatory for POM version 4?)
>
> "Vincent Massol" <vm...@pivolis.com> wrote on 20/11/2003 08:05:18
PM:
>
> > I guess it all depends on the question of whether we wish to link
POM
> > versions to Maven releases. I think, I'm being swayed and I agree
it's
> > cleaner to link them....
> >
> > <thinking some more>
> >
> > Ok, I think I've realized what the problem is: We are developing
1.0-RC1
> > on HEAD. This is the main problem. Normally here's how I would
expect
> > development to work:
> >
> > - HEAD always contains latest development for the *next* release
(that
> > would be 1.1-SNAPSHOT for us)
>
> The next release for us is 1.0, not 1.1-SNAPSHOT. We haven't had a 1.0
> yet.
Yes, of course. But are you saying nobody is allowed to develop for the
following release (1.1) before 1.0 is released? As it is very bad form
to add new stuff to a RC release (only bugfixes are allowed), where do
you suggest people commit new stuff? Somewhere other than HEAD? That
looks really weird as the latest stuff is expected to be on HEAD...
>
> > - Once a beta is released, CVS is branched (that would be
> > MAVEN_1_0_BRANCH for us) and bug fixing happens on that branch while
> > development for the next release continues on HEAD. For us the beta
> > period has lasted too long but we could say that RC goes into a
branch.
>
> This isn't typical for other projects I've been involved with at
Apache.
We sure don't look at the same projects ;-)
> They typically:
>
> - Do beta and RC work on HEAD
> - Once a release is made, create the branch.
> - HEAD becomes the workspace for the next release.
> - Changes to the release happen on the branch, but no active
development
> typically happens there.
Where do you commit new stuff that happens between the phase where you
have RC on HEAD?
>
> > Should this happen (i.e. move RC1 to a branch and start 1.1 dev on
HEAD)
> > then I'm happy to roll back all my changes related to POM4 and
commit
> > them on HEAD (1.1-SNAPSHOT).
> >
> > What do you say?
> Please, lets not do this?
Why? What are other's experience? AFAIK, there's no better way,
especially for projects like Maven where it takes several months between
a RC and a release.
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version 1.0, 1.1, HEAD and BRANCHES (was 1.0 RE: [VOTE] Make groupId
mandatory for POM version 4?)
Posted by di...@multitask.com.au.
"Vincent Massol" <vm...@pivolis.com> wrote on 20/11/2003 08:05:18 PM:
> I guess it all depends on the question of whether we wish to link POM
> versions to Maven releases. I think, I'm being swayed and I agree it's
> cleaner to link them....
>
> <thinking some more>
>
> Ok, I think I've realized what the problem is: We are developing 1.0-RC1
> on HEAD. This is the main problem. Normally here's how I would expect
> development to work:
>
> - HEAD always contains latest development for the *next* release (that
> would be 1.1-SNAPSHOT for us)
The next release for us is 1.0, not 1.1-SNAPSHOT. We haven't had a 1.0
yet.
> - Once a beta is released, CVS is branched (that would be
> MAVEN_1_0_BRANCH for us) and bug fixing happens on that branch while
> development for the next release continues on HEAD. For us the beta
> period has lasted too long but we could say that RC goes into a branch.
This isn't typical for other projects I've been involved with at Apache.
They typically:
- Do beta and RC work on HEAD
- Once a release is made, create the branch.
- HEAD becomes the workspace for the next release.
- Changes to the release happen on the branch, but no active development
typically happens there.
> Should this happen (i.e. move RC1 to a branch and start 1.1 dev on HEAD)
> then I'm happy to roll back all my changes related to POM4 and commit
> them on HEAD (1.1-SNAPSHOT).
>
> What do you say?
Please, lets not do this?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org