Branch and tags while fixing an issue

[Felipe Leme <ma...@felipeal.net>]

Hi all,

I'd like to fix issue MPJAVA-8
(http://jira.codehaus.org/browse/MPJAVA-8) but in order to do so I will
need to change many plugins and hence the fix itself will take a while
(as I will have to write new test cases for each affected plugin).

So, I was thinking about working on a separate branch while this issue
is fixed. If the documentation -
http://maven.apache.org/development/branches.html - is up-to-date (looks
like it is from the Maven/Turbine days), I would need to create on
maven-plugins a MPJAVA8_SPROUT tag and a MPJAV_8_BRANCH branch before I
start the work and then the MPJAVA8_BEFORE_MERGE and MPJAVA8_MERGE tags
afterward.


Is that right? If so, can I go ahead and do the changes?

-- Felipe





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Branch and tags while fixing an issue

[Brett Porter <br...@apache.org>]

> Hmm, I think I wasn't clear in my previous message: the reason I'd like
> to create a branch is that I can work in the issue without messing with
> the main branch (in this case, the 1_0_BRANCH) while all the changes are
> not ready. Once I finish the changes, I would merge them back to the
> main branch (and that 'private' branch could be forgotten). 

There is no 1_0_BRANCH on the plugins. All the plugins are developed on HEAD
previously. If you are going to branch, I just suggested that they be done
individually.

> If I don't
> create a branch, I need to either work in small changes at time or work
> in a lot of changes without committing them back to CVS.

There's never anything wrong with doing work in small changes.

> > code in to set it, and if not set get it from the old property name, it
> should
> > play nicely. I did similarly in the artifact/deploy plugin.
> 
> I don't understand what you mean by 'if not set get it from ...'...

Sorry, I was probably thinking back to front. You actually want to set both and
deprecate one, right?

> Anyway, the fix shouldn't cause backaward compatibility issues, although
> the new final names might change in some cases (for instance, the WAR
> file created at target doesn't have the currentVersion on its name,
> which is inconsistent with the other plugins and even the WAR that is
> installed/deployed).

You need to be careful that you don't break any existing builds with this,
that's all.

Thanks,
Brett


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Branch and tags while fixing an issue

[Felipe Leme <ma...@felipeal.net>]

Brett,

On Sun, 2004-09-05 at 21:03, Brett Porter wrote:

> 1) branching/versioning should be on a per-plugin level, if needed
> 2) changes should be backwards compatible at this stage, indicating that a
> branch may not be needed.

Hmm, I think I wasn't clear in my previous message: the reason I'd like
to create a branch is that I can work in the issue without messing with
the main branch (in this case, the 1_0_BRANCH) while all the changes are
not ready. Once I finish the changes, I would merge them back to the
main branch (and that 'private' branch could be forgotten). If I don't
create a branch, I need to either work in small changes at time or work
in a lot of changes without committing them back to CVS.

> 
> IIRC this is the change to a new .final.name property. I think if you put some

Yes, that's it.

> code in to set it, and if not set get it from the old property name, it should
> play nicely. I did similarly in the artifact/deploy plugin.

I don't understand what you mean by 'if not set get it from ...'...

Anyway, the fix shouldn't cause backaward compatibility issues, although
the new final names might change in some cases (for instance, the WAR
file created at target doesn't have the currentVersion on its name,
which is inconsistent with the other plugins and even the WAR that is
installed/deployed).

-- Felipe





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Branch and tags while fixing an issue

[Brett Porter <br...@apache.org>]

I'll can reply in more detail when I get a chance if needed, but I don't think
this is the right approach.

Two reasons:
1) branching/versioning should be on a per-plugin level, if needed
2) changes should be backwards compatible at this stage, indicating that a
branch may not be needed.

IIRC this is the change to a new .final.name property. I think if you put some
code in to set it, and if not set get it from the old property name, it should
play nicely. I did similarly in the artifact/deploy plugin.

Cheers,
Brett

Quoting Felipe Leme <ma...@felipeal.net>:

> Hi all,
> 
> I'd like to fix issue MPJAVA-8
> (http://jira.codehaus.org/browse/MPJAVA-8) but in order to do so I will
> need to change many plugins and hence the fix itself will take a while
> (as I will have to write new test cases for each affected plugin).
> 
> So, I was thinking about working on a separate branch while this issue
> is fixed. If the documentation -
> http://maven.apache.org/development/branches.html - is up-to-date (looks
> like it is from the Maven/Turbine days), I would need to create on
> maven-plugins a MPJAVA8_SPROUT tag and a MPJAV_8_BRANCH branch before I
> start the work and then the MPJAVA8_BEFORE_MERGE and MPJAVA8_MERGE tags
> afterward.
> 
> 
> Is that right? If so, can I go ahead and do the changes?
> 
> -- Felipe
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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