Re: [tm-dev] R3_4_maintenance branch created

[David Dykstal <david_dykstal@xxxxxxxxxx>]

I'm not sure I understand your question,
but here's an attempt at an answer.

I'm going to guess that the org.eclipse.tm
project's number (3.8.0) matches the eclipse train version.

The maintenance branch is correctly
named R3_4_maintenance. and the target "milestone" is 3.4.2+
for bugs backported to that branch.

-- David Dykstal,  Architect - Rational Developer for Power Systems



From:      
 Jose Manuel Garcia
Maciel/Mexico/IBM <josemg@xxxxxxxxxxx>
To:      
 TM project developer
discussions <tm-dev@xxxxxxxxxxx>, 
Cc:      
 tm-dev@xxxxxxxxxxx,
tm-dev-bounces@xxxxxxxxxxx
Date:      
 03/04/2013 02:32 PM
Subject:    
   Re: [tm-dev]
R3_4_maintenance branch created
Sent by:    
   tm-dev-bounces@xxxxxxxxxxx

---

The job for this new branch is now ready,
but it is still disabled

one qq, the current tm repo version says 3.4.2, 
The org.eclipse.tm project says 3.8.0

The question is, 
what do we need to use for this new branch?

regards,
Manuel Garcia

David
Dykstal ---26/02/2013 23:47:15---I've created the R3_4_maintenance branch
based on what we've committed for Juno SR2.

David Dykstal <david_dykstal@xxxxxxxxxx>
Sent by: tm-dev-bounces@xxxxxxxxxxx

26/02/2013 23:47

Please respond to
TM project developer discussions <tm-dev@xxxxxxxxxxx>

To	tm-dev@xxxxxxxxxxx
cc
Subject	[tm-dev] R3_4_maintenance branch created

I've created the R3_4_maintenance branch based on what we've committed
for Juno SR2. 

If I'm reading the version numbering rules correctly all work on the master
branch that makes binary compatible changes should increment the 3rd component
of the version number of the containing bundle to the next 100 over the
R3_4_maintenance branch. For example, if the bundle is 3.1.203.qualifier
in the R3_4_maintenance branch then modifying a bundle element should cause
the version number to be 3.1.300.qualifier. This leaves room in the 3.4
maintenance branch for binary compatible changes that would increment the
3rd component by 1. 

Upward compatible changes that are not downward compatible should increment
the 2nd element of the version number by 1 in the master branch.

Of course, changes intended to be backported to R3_4_maintenance should
be made in the master branch first. 

We now need to get a build job running to produce maintenance builds for
this. It looks like Manuel has begun that process.

I will be creating appropriate "releases" in bugzilla for any
3.4 maintenance work tomorrow. 

-- David Dykstal,  Architect - Rational Developer for Power Systems_______________________________________________
tm-dev mailing list
tm-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tm-dev

_______________________________________________
tm-dev mailing list
tm-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tm-dev