Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[orbit-dev] Orbit Build process ready for review and contributions]

> 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
> ->

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
(which is very nearly, but not quite, an exact copy of what would be in set2 or set1).

Then, a new <ant element in
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.

Back to the top