Re: [vtp-dev] Bundle Versions

[Trip Gilman <trip@xxxxxxxxxxxxxxx>]

After doing some research on how other projects manage their version numbers
I came to the realization that version (at least when you are talking
bundles) is a release management thing, not a development thing.  The trunk,
or where ever the primary development occurs, is frozen in time with the
same version number.  The differences in builds is handled by the
".qualifier" extension on the bundle version.

PDE build is smart enough to replace this with the current time stamp
(yyyymmddhhmmss) when exporting to a bundle or using the headless build.
This allows the developers to load the latest version of the plugins without
having to hack the manifest file all the time.

At the point of release the version numbers of all bundles are updated to
the release version and then tagged in the repository.  The maintenance work
will be done in this new work stream and under that version. e.g. 3.1 gets
tagged and the next bug fix release is tagged as 3.1.1.  All the development
done until 3.1.1 will be listed as 3.1.0.qualifier.  We could do the
development under 3.1.1.qualifier if that sounds better.

Trip Gilman


On 5/1/09 12:12 AM, "Mike Greenawalt" <mike@xxxxxxxxxxxxxx> wrote:

> I do not see how the idea of "same" version number can work so long as
> there are committers working on different parts of the project in
> independent fashion. I can assign any version number you want to my
> plugins now, but as soon as I solve the problems that have prevented me
> from finishing the changes that I started 2+ years ago, the version
> number would need to change.
> 
> How do you expect to manage this?
> 
> -- Mike
> 
> Trip Gilman wrote:
>> All,
>> 
>> I have updated the desktop, framework, and new documentation component
>> plugins to a new version number 3.0.25.qualifier.  I'd prefer to keep all
>> the components at the same level and have a single version number for the
>> entire product component set.  I think it makes the docs easier and the
>> overall package more understandable.
>> 
>> I have chosen to use 3.0.25 as that is the internal version number we were
>> operating on over at OpenMethods prior to fully migrating everything over to
>> the VTP.  There are @since and other comments in there that reference these
>> versions and such.
>> 
>> I expect that it will make sense to use 3.1.0 as the official number for our
>> next release.  We'll create a maintenance stream in SVN at release that will
>> house the 3.1.x builds and the trunk will move to 3.2.  I know this is all
>> rather confusing but I figured it was a good time to do it since we will
>> have a continuous build in place and will be preparing to release.
>> 
>> Trip Gilman
>> 
>> _______________________________________________
>> vtp-dev mailing list
>> vtp-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/vtp-dev
>> 
>>   
> _______________________________________________
> vtp-dev mailing list
> vtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/vtp-dev