Mike, You got it. The version number of the bundles (in the manifest) is pretty much meaningless in the trunk and branches and only really get applied when we tag a release. The VTP build system is almost up and running. Adam and I were working on it this week. I think we have everything building now using the CBI framework and are just waiting for some provisioning on the Hudson server. It should be available some time next week.
Trip Gilman On 5/1/09 2:44 AM, "Mike Greenawalt" <[email protected]> wrote: > 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" <[email protected]> >> <mailto:[email protected]> 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 >>>> [email protected] >>>> https://dev.eclipse.org/mailman/listinfo/vtp-dev >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> vtp-dev mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/vtp-dev >>> >>> >> >> >> >> >
_______________________________________________ vtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/vtp-dev
