| Re: [vtp-dev] Bundle Versions |
I like the idea that version numbering is handled as part of the release management process, not development.
If there is version "x" of a plugin that goes with version "x" of the project, and then there is need to create a new version "y" of the plugin before the project has a general new updated version number, then that is handled by branching in the repository. Sounds logical to me.
What is the current ETA of a properly built VTP? Any idea at this point?
-- Mike
Trip Gilman wrote:
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> <mailto: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