You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2005/11/23 06:07:30 UTC
[vote] 2.0.1/2.1 dev process
This thread never really got rounded up, so I thought I'd summarise some
points we seemed to be in agreeance on. Please vote +1 for all, or
+1/+0/-1 for every item.
- use of the flying fish technique (ie bugfix only release goes over to
/branches/2.0.x)
* we should merge at each point release (2.0.1, 2.0.2) back to trunk
* can do interim merges if there are long time lines on those releases
* we need to set up multiple CI processes
- no alphas or betas on 2.0.x releases
- current version is always <final release>-SNAPSHOT, eg 2.1-SNAPSHOT
- 2.1 cycle will have betas (maybe alphas), which are labelled at
release time (release plugin to accommodate)
- RC's are the actual build. It will report version "2.0", and is
differentiated from the actual final release (if different), by the
build timestamp. If the RC is not suitable for any reason, we remove the
old tag, and redo the release
- we will setup one new JIRA project per plugin (prefix with just M,
won't be reusing the m1 projects, and we'll move all existing issues to
there even if closed - based on component)
The same should also apply to Continuum.
If we agree on this, then the first step is:
svn cp https://svn.apache.org/repos/asf/maven/components/trunk
https://svn.apache.org/repos/asf/maven/components/branches/2.0.x
and everyone svn switches to that if they are doing core bugfixes. John
- can you do this?
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: build labelling was: [vote] 2.0.1/2.1 dev process
Posted by Brett Porter <br...@apache.org>.
Jason van Zyl wrote:
> Brett Porter wrote:
>
>> - RC's are the actual build. It will report version "2.0", and is
>> differentiated from the actual final release (if different), by the
>> build timestamp. If the RC is not suitable for any reason, we remove
>> the old tag, and redo the release
>
> Can you expand on this and possibly through series
> of version names to illustrate the movement toward a release?
>
I may be getting ahead of myself :)
as far as pom goes:
2.1-SNAPSHOT
2.1-alpha
2.1-SNAPSHOT
2.1-beta-1
2.1-SNAPSHOT
2.1
where 2.1 gets put out as 2.1 RC1, and renamed 2.1 when it is tested as
good.
The goal is to not rebuild code that was tested as an RC for a couple of
reasons:
- so you release what you actually test
- to avoid risk of environmental factors producing a different output to
what was tested
- to save work in going through the release process all over
The problem with this, which was an issue in the 2.0 release, was that
the 2.0 JARs get deployed as part of the process and are now "out there"
in the repository.
I think the solution to this is for snapshots, alphas, betas and rcs to
all be deployed to the development repository, and only after successful
testing be moved to the release repository (so ibiblio wouldn't have
alpha and beta code in the same way it doesn't have snapshots). The
problem is that we can't do that just yet :)
We have another issue - because Maven operates off the repository, it
needs to find all its JARs. This entails putting the development
repository into the configuration for the distribution (I think in a
profile in $M2_HOME/conf is probably more appropriate than the super
POM), but this won't work for the RC - maybe the RC requires a manual
step by the user to test for this case.
Anyway, we aren't quite there yet, so I'll step this back and say we
just rebuild/tag as usual for an RC and for the final (where the final
shouldn't have any changes since the last RC). I think doing the above
repository step is possibly a good idea though.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] 2.0.1/2.1 dev process
Posted by Jason van Zyl <ja...@maven.org>.
Brett Porter wrote:
> - RC's are the actual build. It will report version "2.0", and is
> differentiated from the actual final release (if different), by the
> build timestamp. If the RC is not suitable for any reason, we remove the
> old tag, and redo the release
Can you expand on this and possibly through series
of version names to illustrate the movement toward a release?
> - we will setup one new JIRA project per plugin (prefix with just M,
> won't be reusing the m1 projects, and we'll move all existing issues to
> there even if closed - based on component)
>
> The same should also apply to Continuum.
>
> If we agree on this, then the first step is:
> svn cp https://svn.apache.org/repos/asf/maven/components/trunk
> https://svn.apache.org/repos/asf/maven/components/branches/2.0.x
>
> and everyone svn switches to that if they are doing core bugfixes. John
> - can you do this?
>
> Cheers,
> Brett
>
> ---------------------------------------------------------------------
> 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: [vote] 2.0.1/2.1 dev process
Posted by Brett Porter <br...@apache.org>.
Alan D. Cabrera wrote:
> Brett Porter wrote, On 11/24/2005 4:23 PM:
>
>> My thoughts:
>> - this is more risky that it will be missed if someone misses one
>>
>>
> This is not as likely if the commits are made to both lines at the same
> time.
I don't understand this reasoning. If using this technique, if one is
missed, you have to backtrack and find what was missed.
If you use the weekly technique (or whatever interval), you are merging
everything since last merge ensuring nothing is missed.
> Also, there will be times when it will not make sense to apply
> the branch change in the trunk. You want the original patch author to
> make that investigation and decision at the time of the checkin not a
> "third party" branch merger at the time of a branch merge.
I don't exactly agree. The only case where I feel something should go
onto the branch and not the trunk is if that functionality was removed
on the trunk for some reason. In that case, the merge will conflict on
that change and it can be easily thrown away.
Do you have a specific use case?
>
>> - its more cumbersome on an individual commit
>>
>>
> Not more cumbersome. Waiting to do the work at the uber merge merely
> postpones the inevitable.
I can't agree here. Assuming no review, per commit adds a command for
every commit, per week adds a command per week. Getting into review
stage - you've already said that the review is the same at either point.
I'd prefer to do them sequentially myself. I understand that there
might be some issues that require the original author to be involved.
In this case I'd instead encourage authors to still be aware of the
affect of their changes and if they think they will be problematic - to
call for an early merge to raise a flag on it. That fits the community
style better too :)
> Blind merges that just dump whatever is in a
> branch into the trunk are always dangerous without careful scrutiny;
> performing this due diligence makes it the same, usually more, amount of
> work as individual multi branch commits.
I agree blind merges are bad. When I do it, I always review the
resulting commit to ensure it still makes sense. And aside from that,
you rely a lot on your automated testing to ensure everything is still sane.
I see where you are going, and it probably becomes more the case as you
get to a much larger project size than what we are dealing with (100's
of developers instead of 10's). The fact is that the majority of commits
in the project at present are comfortably isolated and merge nicely.
> And you want to know of the clash and have that discussion asap, at the
> time of the checkin, not later. Issues like this need to be resolved
> before the trunk evolves further and while things are still fresh in
> everyone's mind.
That's true. I've thought about Maven tracking last merge points and
allowing CI to automatically perform that merge on the trunk
automatically and alert when it has a conflict and then let someone
resolve that, and then test the build.
> The paradigm I espouse applies to what ever product management style
> that is in place. The issues that I raise are not as relevant for more
> mature product lines that do not change that radically. But it has
> always been my experience that a "blind" merge at the end of a branch
> release is always more work and error prone than "multi branch" checkins.
>
> Just my 2 cents. :)
That's fair enough, but I just don't see it here where we are doing very
little (well, currently no) trunk work. And its super tedious and
anything tedious is error prone. I'd grumble about doing it, and
anything you have to grumble about is going to cause some sort of issues.
Others are welcome to disagree with me :)
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] 2.0.1/2.1 dev process
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Brett Porter wrote, On 11/24/2005 4:23 PM:
>My thoughts:
>- this is more risky that it will be missed if someone misses one
>
>
This is not as likely if the commits are made to both lines at the same
time. Also, there will be times when it will not make sense to apply
the branch change in the trunk. You want the original patch author to
make that investigation and decision at the time of the checkin not a
"third party" branch merger at the time of a branch merge.
>- its more cumbersome on an individual commit
>
>
Not more cumbersome. Waiting to do the work at the uber merge merely
postpones the inevitable. Blind merges that just dump whatever is in a
branch into the trunk are always dangerous without careful scrutiny;
performing this due diligence makes it the same, usually more, amount of
work as individual multi branch commits.
>- the merge is not just the patch authors knowledge, but also the trunk
>changers knowledge, so its not always that simple if there is a clash so
>it might require some discussion
>
>
And you want to know of the clash and have that discussion asap, at the
time of the checkin, not later. Issues like this need to be resolved
before the trunk evolves further and while things are still fresh in
everyone's mind.
>I agree sooner is better (I'd probably lean to weekly in general, but
>the way I see the Maven dev focusing on 2.0.1, then 2.0.2 with
>infrequent 2.1 implementation until they are done, I think this is more
>manageable).
>
>
The paradigm I espouse applies to what ever product management style
that is in place. The issues that I raise are not as relevant for more
mature product lines that do not change that radically. But it has
always been my experience that a "blind" merge at the end of a branch
release is always more work and error prone than "multi branch" checkins.
Just my 2 cents. :)
Regards,
Alan
>- Brett
>
>Alan D. Cabrera wrote:
>
>
>>Brett Porter wrote, On 11/22/2005 9:07 PM:
>>
>>
>>
>>>- use of the flying fish technique (ie bugfix only release goes over
>>>to /branches/2.0.x)
>>> * we should merge at each point release (2.0.1, 2.0.2) back to trunk
>>> * can do interim merges if there are long time lines on those releases
>>>
>>>
>>>
>>It has always been my experience that merges back to th trunk should be
>>done immediately, by the original patch author, while it is still fresh
>>in one's mind. The problem of merging back to the trunk at the point
>>release becomes even worse when code has been modified in the trunk.
>>
>>
>>
>>Regards,
>>Alan
>>
>>
>>
>>---------------------------------------------------------------------
>>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: [vote] 2.0.1/2.1 dev process
Posted by Brett Porter <br...@apache.org>.
My thoughts:
- this is more risky that it will be missed if someone misses one
- its more cumbersome on an individual commit
- the merge is not just the patch authors knowledge, but also the trunk
changers knowledge, so its not always that simple if there is a clash so
it might require some discussion
I agree sooner is better (I'd probably lean to weekly in general, but
the way I see the Maven dev focusing on 2.0.1, then 2.0.2 with
infrequent 2.1 implementation until they are done, I think this is more
manageable).
- Brett
Alan D. Cabrera wrote:
> Brett Porter wrote, On 11/22/2005 9:07 PM:
>
>> - use of the flying fish technique (ie bugfix only release goes over
>> to /branches/2.0.x)
>> * we should merge at each point release (2.0.1, 2.0.2) back to trunk
>> * can do interim merges if there are long time lines on those releases
>>
>
>
> It has always been my experience that merges back to th trunk should be
> done immediately, by the original patch author, while it is still fresh
> in one's mind. The problem of merging back to the trunk at the point
> release becomes even worse when code has been modified in the trunk.
>
>
>
> Regards,
> Alan
>
>
>
> ---------------------------------------------------------------------
> 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: [vote] 2.0.1/2.1 dev process
Posted by Carlos Sanchez <ca...@apache.org>.
I agree that they should be done no less than once per week.
About RCs I think we should tag them as that and add the 2.1 tag when
the RC is accepted. We shoudn't remove the RC tags because we may want
to reproduce the build for any reason.
I'm fine with the other stuff
On 11/24/05, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Brett Porter wrote, On 11/22/2005 9:07 PM:
>
> > - use of the flying fish technique (ie bugfix only release goes over
> > to /branches/2.0.x)
> > * we should merge at each point release (2.0.1, 2.0.2) back to trunk
> > * can do interim merges if there are long time lines on those releases
> >
>
>
> It has always been my experience that merges back to th trunk should be
> done immediately, by the original patch author, while it is still fresh
> in one's mind. The problem of merging back to the trunk at the point
> release becomes even worse when code has been modified in the trunk.
>
>
>
> Regards,
> Alan
>
>
>
> ---------------------------------------------------------------------
> 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: [vote] 2.0.1/2.1 dev process
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Brett Porter wrote, On 11/22/2005 9:07 PM:
> - use of the flying fish technique (ie bugfix only release goes over
> to /branches/2.0.x)
> * we should merge at each point release (2.0.1, 2.0.2) back to trunk
> * can do interim merges if there are long time lines on those releases
>
It has always been my experience that merges back to th trunk should be
done immediately, by the original patch author, while it is still fresh
in one's mind. The problem of merging back to the trunk at the point
release becomes even worse when code has been modified in the trunk.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org