[orbit-dev] Orbit Build process ready for review and contributions]

[David M Williams <david_williams@xxxxxxxxxx>]

> 1). Do you think that we should be using the
branch name as part of the tag
> when we version? I was releasing changes to org.junit (both streams)
and I
> ran into problems because I used the v200701261100 version tag for
both
> streams. So then I created one with a v200701261101 tag but it became
hard
> to remember which branch this one was for, etc. Would it be ok to
use
> something like v3_8_2_20070126, etc?

I'd prefer not. Somehow seems _overly_ redundent to
me, and a little primitive, 
like physical file system is primitive. :) Plus, I've
seen 
many user-errors made using that convention, since
it can be hard to 
be sure that initial part stays monotonic. I'm not
sure of the context you need 
to associate branch with version tag, but should be
rare, right? And there's 
tools such as "load from map file" which
might help? Plus, it makes the ugly 
version qualifiers even uglier. (Ok, I admit, I hate
the 
idea, but didn't want to sound too strong about it,
in case many others wanted 
it that way ... I really would learn to adapt :) 

> 2). If we can update the builder to be running on the latest version
of
> PDE-Build, that would be cool. There was a bug that Pascal fixed which
> allows for qualifier replacement in the middle of strings that we
will need
> when we have a bundle that already has a 4 part version. (e.g. org.junit
> 4.1.0.1_qualifier -> 4.1.0.1_20070126)

Yes, I'll look into it this weekend, but ping me if
it gets to be anything thats 
holding you up. As I do it, I'll write up some "how
to" for the build wiki, so others know 
how to do more easily. (Or, if you've already figured
it out ... feel free!). 

> 3). What is the process for adding additional versions to the build?
(e.g.
> a 3rd version of a plug-in) I would assume the following steps but
wanted
> to confirm with you before doing it: create a new branch of the releng
> project and use an empty map file with just your new bundle's entry,
create
> a new feature project following the naming convention (.set3) and
add your
> bundle to the feature.xml.

You've listed everything except, I've found it easy
to forget, when that new 
map file is created, be sure to also include the new
feature, the first time, 
in addition to your new bundle. 

Plus, some small updates to the "releng"
components ... I'd be happy to do, and 
document as I go, but briefly: 

add a 'set3' compnent to 
org.eclipse.orbit.releng.builder\components
(which is very nearly, but not quite, an exact copy
of what would be in set2 or set1). 

Then, a new <ant element in 
org.eclipse.orbit.releng.builder\distribution\orbit.build\build.xml
that is very nearly, but not quite, an exact copy
of the other <ant elements there. 

And, just to note it here, to get "auto build"
to work, we have to update the cc_config.xml 
in org.eclipse.orbit.releng.control 
to be sure to "watch" the set3 branch of
the releng project.