Community
Participate
Working Groups
EMF produces development drivers on their update site. A lot of people like this, being able to use the update manager for builds too. We would like to start doing this for VE also. But the problem is the version naming that needs to be used. For example, if they are developing for verson 2.0.2, then the versions of the plugins/features during development are named 2.0.2.I20041001 to indicate the build id of it. The problem occurs when they publish the final released 2.0.2. The problem is that to the update manager it thinks 2.0.2 is downlevel from 2.0.2.I20041001 and so it won't allow an update. The user must physically remove it from the configuration by hand, do a -clean, and then apply the final 2.0.2 update. My suggestion is allow a convention like: 2.0.2.dev_I20041001 to indicate this is a development version of 2.0.2, so that 2.0.2 will be considered to be up-level from the development version. The update manager would need to be changed to see the dev_ as being downlevel. And if you are trying to do 2.0.2.1, then use 2.0.2.1_dev_I20041001 to indicate this is a development driver of 2.0.2.1 and so 2.0.2.1 will be considered to be up-level from 2.0.2.1_dev_I20041001. Here the _dev_ would be considered downlevel. However, within the dev, the rest of it would still apply. In other words, dev_I20041006 would be considered uplevel from dev_I20041004 (using the same string sort order used now on the fourth part of the version). Thanks.
Rich, would the milestone builds be numbered as 2.0.2.M3 or something similar? Just going by I builds may not be what the community wants, as many people prefer to pick up stable builds. In this case, it would be problematic to update from M1 to I build that follows, unless we modify your proposed scheme. I suggest you propose these changes on eclipse-dev and/or platform-update-dev so others have some input before getting down to implementing it (the implementation should be relatively straighforward).
I see two problems to this approach: - it puts semantics on a number something that does not have one. - it forces a renumbering or rebuild of the plugins when we are ready to ship. The first one is unfortunate because we already ship plugins that makes use of the 4th segment and that we do not necessarily control the version scheme (for example lucene), the second approach has already been tried and refuted in the past because it puts extra burden when we are about to ship, many files may need to be updated (plugins, features, ini files) introducing potential perturbations. Another problem is that you tag as 2.0.2 because you are sure it is the last version, but then you see a last bug that must be fixed... how do you handle that? A few months ago we proposed the usage of meaningfull version numbers (see http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core- home/documents/plugin-versioning.html) but it's been rejected because with the argument that we want to show people a nice version number like 3.0.0 instead of 3.0.0.3. Since then I thought that a solution could consists in adding an extra field in the features and plugins called buildId. This buildId would be free form and would mainly be used by update to support upgrade from 3.0.1 build I2004 to 3.0.1 build I2005. In this case the build id would not take precedence over the version id.
The pollinate team has been discussing this as well. We tentatively have worked out the following approach for our update site: integration builds = 1.0.0.I<date> (e.g. 1.0.0.I20040904) milestone builds = 1.0.0.M<number> (e.g. 1.0.0.M1) release candidate = 1.0.0.RC<number> (e.g. 1.0.0.RC1) final release = 1.0.0.Release Since the forth position is sorted alphanumerically, this versioning scheme causes the release to take precedence over the release candidates, which take precedence over the milestones, which take precedence over the integration builds. The two problems I see are a) the release cannot be named "1.0.0" but rather must be "1.0.0.Release" b) in order to move from a milestone (e.g "1.0.0.M1") to a later integration build (e.g. 1.0.0.I20041101), you have to uninstall and then reinstall that feature. Changing the update manager so that "1.0.0" took precidence over "1.0.0.X" would be helpful, but change the semantics in a breaking way.
A better scheme for milestone builds would be 1.0.0.I<date>_M<number> as, milestone builds are still integration builds, with additional "blessing" This way, you can update from an M build to the following I build.
True, "1.0.0.I<date>_M<number>" would allow an integration build to take precedence over a milestone, but I view milestones as inherently more stable than integration builds. For example, I rarely load Eclipse integration builds, but almost always load milestones. For Pollinate, I would want a user to consciously choose an integration build rather than having them automatically offered the integration build as "better" than the currently loaded milestone. I would recommend changing the update manager so that the user could optionally choose to install what the update manager perceives as an "earlier" release. A modification like this to the update manager would not change the way that the version is interpreted and thus would not be a breaking change. I could see an update site containing the two latest integration builds, the milestone builds for code under development, and all past releases. I would be nice if the update manager would "suggest" a version to install but allow a user to choose differently.
The challenge here is maintaining the semantics of the version numbers. Eclipse puts forth (though sadly does not use) a convention that has Major.minor.serivce.qualifier with relationships betwen them like: - change service => bug fixes - chnage minor => additional function/API - change major => significant and API changes This naturally leads to a situation where the plugin version numbers do not match up with the product release numbers. By this logic some of our plugins would be 1.1.4 and others would be 5.2.0. This makes alot of sense. Consider update in the current situation where we up the version numbers for all plugins for each release. We went through extreme effort to make 3.0 backward compatibile with 2.1 and were largely successful. However, we upped the version numbers so all existing plugins that spec'd a version number on a required plugin got hosed (3.0 is not "compatible" with 2.1 since the major number changed). Bummer. Any scheme that bases plugin version numbers on product version will suffer the same problems. The challenge with this approach is how ot handle maintenance streams. You get to 1.2.1 and then ship. Then you want to continue with new developement but might need to do some bug fixes. What is the next version number in each stream? For added fun assume that all you want to do is the same bug fix in both streams but in HEAD you need to call some new method supplied by another plugin while in the Maintenance stream you need to use some old method. In both cases the changes to your plugin are bug fixes. So the next version should be 1.2.2. Of course, they can't both be 1.2.2. You can use the qualifier (4th segment) but things do get a bit hairy trying to keep it monotonically increasing. One option is to do the Linux sort of odd/even approach. Odd for development, even for release (or vice versa).
Is there any reason besides aesthetic clutter in the plug-in version ids not to just use service.major.minor.buildid *all the time*? buildid is YYYYMMDDHHMM, for example 3.1.0.200410281200 . No M's, I's, S's, RC's, or whatever, and no omitting it to muck up the sorting. The About>Plugins dialog could trim the text if you just want a pretty list.
This will not solve the problem of service versions, such as 3.0.1.1 Would 3.0.0.1 be a smaller version than 3.0.0.200406261200 ? To deal with multiple branches, the version qualifier would have to be used, at least in the current versioning support.
similarly, it is not build id that you want really. You want CVS content tag. If you use build id then everything changes every build and update is rendered useless. The version number really should reflect the content of the plugin. As Dorian outlined, it is the multistreaming that causes the headache (regardless of which approach you use). There are two things later than x.y.z (HEAD and Maintenance stream content) but they do not have an update relationship between them.
3.0.0.1 would not be a valid number. I'm saying why not make the 4th position always be something monotonically increasing (a build number or maybe a cvs content tag). For example using build numbers (aka date/times) here's how things would sort: org.eclipse.core.runtime_3.0.0.200406251208 - 3.0 release org.eclipse.core.runtime_3.0.1.200409161126 - 3.0.1 release org.eclipse.core.runtime_3.1.0.200408122000 - 3.1M1 stable stream org.eclipse.core.runtime_3.1.0.200409240800 - 3.1M2 stable stream org.eclipse.core.runtime_3.1.0.200410260800 - last 3.1 integration org.eclipse.core.runtime_3.1.0.200410290010 - last 3.1 nightly
This is fine but it relies on the broken use of the first three version segments. The maintenance and HEAD streams are separated by changing from 3.0 to 3.1. As I mentioned earlier, this breaks update (in some cases) and renders invalid many otherwise valid/legitimate version constraints.
3.0.0.1 is a valid version. It stands for an emergency fix on 3.0.0.
It doesn't seem like we are coming to a concensus. Everyone wants a different style. Maybe we could agree on something like this: 1.0.0._yada or 1.0.0.1_yada means 1.0.0 would always be newer than 1.0.0_yada and 1.0.0.1 would always be newer than 1.0.0.1_yada, and where everything after the "_" would be monotonically increasing. This way if you don't use the "_", nothing has changed. If you use the "_", then you can choose whatever scheme you want to use. Those who don't want to use it don't have to. My intent would be to use it like: _YYYYMMDD_I or _YYYYMMDD_RC1 or YYMMDDa_I (for if this is the second build on the same day). Then the update manager would show by increasing build date. And if someone didn't want I drivers, they can just ignore them and wait for the RC drivers. And by putting the I or RC at the end, someone wanting to switch from an RC to a later I build will see the I drivers because the build date is first in the scheme and will cause it to sort newer than the current installed RC driver. If RC was first in the version id, then this wouldn't happen because the RC would prevent any of the I drivers from showing. There would be no need to uninstall the RC driver to get the I driver to show up in the list.
It's been a week and no further responses. Can this be accepted and implimented, or does anyone object? Thanks.
I'll probably be the one implementing whatever we decide on, but I, too, would like to hear some consensus on a proposal. As for your latest proposal, the change that I'd suggest is replacing the _ as the separator, with something else, perhaps # (I need to check if this is an xml special char). I've seen _ used in some people's version qualifiers, so I'd rather not give it a special meaning.
I have no problem with changing the separator. Sounds good because I think you are right, I think I have seen _ used.
Sorry, I got a little lost here. What exactly is being proposed in terms of implementation changes?
comment 13 is the last proposal. It is to allow 1.0.0 to be greater than 1.0.0.#xyz while 1.0.0.#zzz would be greater than 1.0.0.#xyz. (where # is used instead of the first suggestion of _). This would allow people to use the formats that they desire, such as in comment 3 , comment 4 , and comment 10 or to not use it all and stick to the current format.
Ok, concretely then the proposal is to change all version comparison code throughout Eclipse to have this characteristic. Right? I desperately want to solve this problem but am nervous about this approach. There are a number of places that would need to be changed (search algorithms in Main and EclipseStarter, Version, update, ...). Some of these are quite sensitive. The kicker for me however is the incompatibility with the OSGi version spec. We are proposing that OSGi R4 have versioning semantics along the lines of those in Eclipse. This complexity would not likely fly in the standards body. The result would be that management agents (for example) written for OSGi would not honour the proposed scheme and the plugin structures being created would not behave as expected.
Note also, that it also does not address the issues raised in comment 6 and comment 9. The basic problem is how to identify progress in the different streams (maintenance and current). Second note (just to make sure it is not lost): you really want to avoid build date based tags. If you use build dates then everything changes all the time and the value of update is shot. The version should be based on content.
This is only for development builds that I would be using this. The released builds would not have this stuff on it. Development builds are increasing by date and so later dates should be complete replacements. But since this seems to be too giving too many people misgivings, I guess I should just withdraw this request.
Rich, your request is valid, and most, if not everybody, cc:ed here would like to update from build to build (I am actually keen to see this, because update will get some badly needed testing :-) What is needed is a spec that would address all the issues raised, or some aggreement on trade-offs.
As noted in the first comment, EMF uses versions like 2.1.0.200410281648 on their update site. This works well except for two problems: Problem 1. When they publish the final released 2.1.0, The version string "2.1.0" is less than "2.1.0.200410281648" in the normal sorting order. So a user can't update to the final released version because update manager will think it's older and not use it. Solution: Just keep the last part of the version string even for the final release. For example "2.1.0.200412010000" is greater than "2.1.0.200410281648". I think this means you can't use "I" or "R" or whatever in the version string but I that should be ok. Problem 2. Jeff says, you really want to avoid build date based tags. If you use build dates then everything changes all the time and the value of update is shot. Solution: Have four different update sites for each top level project, one for Release/Maintenance, one for Stable, one for Integration, and one for Nightly. The user subscribes to whichever one they are comfortable with and sticks with it. Update still has value because it can do automatic download and install. (Aside: Actually I'm one of those people that like my numbers to all match up so I can be sure that I have a set of plug-ins that will work together. If one is v101 and one is v315 and one is v242 and one is v511 and so forth, then yes that could reduce downloads and disk space but it would also decrease my faith in the coherance of the installation. However, I may be in the minority so if the consensus disagrees then maybe it would be possible to avoid building and renumbering a project if nothing changed in it. Either way, with multiple update sites, update is still very useful.)
My problem is I don't like to have the build id attached to released versions. I want them removed and have them there only for development. It makes it very clear that is a released version instead of a development driver because it has no build date attached.
Are you saying you don't want them on disk, or you don't want to see them in the About box, or you don't want to see them in the Update Manager? Actually I was hoping to avoid the "if you already have build X you don't need to download 3.1 production because it's the same" type of messages. But just for you... Solution part 3: Strip the last component of the version string in the ant script that creates the Release update site (only). As long as a user stays with one site, i.e., they always use Release or they always use Integration, they won't have Problem 1 above. (And if they're sophisticated enough to switch update sites then they can figure out how to delete the Eclipse tree and start over with a clean install if necessary. But that should be the exception not the rule.)
I didn't want the build ids to be on the disk or visible, but that is only for release build. Those are for the non-adventurous people who want to stay release only. They would stay around for development builds. If you are pulling the development drivers, then you need the build ids. I was trying to make going from development to Release a lot easier. (By the way I do intend to have two different updates site, one for release and one for development, so that release users don't need to be inundated with all of the development stuff). But if I require uninstall and then install to go from development to release, then no changes are required. I can do that now. :-)
Some points: - I still feel like the questions in comment 19 are unanswered. What if any code changes are being proposed? - ditto on comment 22. - Perhaps a nit... in comment 23 Ed is talking about wanting version numbers to match up and cites numbers like v101, v315, ... I assume from the form that those are actually the fourth segment and that it is assumed that the first three are something like 3.1.0. What I have been on about is that the 3.1.0 is just plain WRONG. If the version number/matching semantics put forward in Eclipse were correctly used, all plugins for a given release would likely have different version numbers since the numbers would be based on the rate/degree of change of the content of the plugin not any outer context. This is a very important point. - IMHO special ant scripts that strip version info etc are really grotty. If you buy the above points re version number integrity then this sort of striping is not needed. - in the end all the discussion of version numbers matching each other and the release would be moot if there were a simple utility that checked the versions against a release list. - multiple update sites is likely the answer somehow. Four seems like a lot. Perhaps just one per release (e.g., 2.0, 2.1, 3.0, ...). These would contain the development (I and M) releases, then release, then maintenance releases associated with each stream. If "correct" version numbering were used, the same plugin might appear in several sites if it did not change.
I have updated the plugin versioning proposal (http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core- home/documents/plugin-versioning.html) to include the notion of "release families" as a way of getting the correct semantics for the first three version segments but still being able to disambiguate independent changes from multiple streams (e.g., a minor change in HEAD and a minor change in the Maintenance stream). Note also that the issue of warm fuzzies is treated more thoughly. You might also be intersted in the updated version of the update site proposal as well http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-core- home/documents/update.html
Two things: - The release number should be 3 digits so we can have more than 10 streams. - Are the warm fuzzies computed from what is installed on disk, or the resolved bundles in the current instance.
Jeff, I mostly agree with your proposal in comment #28, but instead of overloading the qualifier string, I'd vote for your other suggestion in comment #6, to use odd/even numbers for releases/development (or the other way around): For example, if 1.0.0 is a release, then 1.0.2, 1.0.4, .., 1.2.0, 1.2.2 etc. would be valid releases. Then 1.0.1 would be the development stream for the 1.0.2 service release, and builds for that streams would be 1.0.1.20041122, etc. (there will be in fact no 1.0.1 build) Similarly, 1.2.0 would be next minor release, and all the builds for it will be 1.1.x.20041122.
If I am to understand correctly about not incrementing a plugin version before it's time, then the plugin developer will need to let the feature.xml writer know when it has a new prereq plugin to add to the feature's list of requireds. And also to let the feature writer know when the prereq version changes too. Actually this part could be automated into the PDE since it can look at all of the plugins in the feature and see the list of required plugins. Also, I presume that it means that the feature.xml should not pre-req features anymore but should instead pre-req plugins. But this presents a problem to the update manager because for a feature to be downloaded that needs a different pre-req'd plugin version then the one loaded, where it does it find the necessary feature and version that contains this pre-req'd plugin? That's what was nicer about pre-req features instead of plugins in the feature xml, it is an easier group to keep together. Otherwise you would get a mish-mash of plugins.
(In reply to comment #30) > For example, if 1.0.0 is a release, then 1.0.2, 1.0.4, .., 1.2.0, 1.2.2 etc. > would be valid releases. > Then 1.0.1 would be the development stream for the 1.0.2 service release, and > builds for that streams would be 1.0.1.20041122, etc. (there will be in fact > no 1.0.1 build) > Similarly, 1.2.0 would be next minor release, and all the builds for it will > be 1.1.x.20041122. I also like this versioning scheme. It's used very often in the Open Source world. However, I think it will be really hard to explain our commercial product managers and our customers why the next release number in the development plan is two steps forward and not one... Having said this, I think such a versioning scheme is targeted at developers who are experimenting with the latest builds. No customer is doing this. I would be happy if we can introduce something in the update manager that marks a version as NOT stable. There would be a preference (disabled by default) like "Show unstable releases". If that's turned on the update manager will offer to upgrade to such a version. The usual decision rules for detecting newer version (using the qualifier) will apply. Anything starting with 3.2.0 and marked as unstable would be lower than anything starting with 3.2.0 and not marked. 3.2.0 (unstable) 3.2.0.1 (unstable) 3.2.0.20051010 (unstable) 3.2.0 3.2.0.1 3.2.0.20051010 3.2.1 (unstable) 3.2.1.1 (unstable) 3.2.1.20051010 (unstable) 3.2.1 3.2.1.1 3.2.1.20051010 The only problem that is left is how to upgrade from 3.1.0 (unstable) to 3.1.0. My initial approach was to not reflect the unstable flag into the qualifier. But this would prevent such an upgrade and I think that's a NOGO from the Platform. The only solution I see now is to use a special char-sequence (e.g. ".dev") in the qualifier if the unstable flag is set. The update manager would than fetch 3.1.0 unstable builds and they will be placed as 3.1.0.dev ... and we are back to the problem that the runtime is not able to recognize 3.2.0 or 3.2.0.1 as a better version than 3.2.0.dev or 3.2.0.1.dev.... Mhm... Any ideas?
This problem is being adressed in the bug #99393 and more precisely by the proposal https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393
I suggest that we mark this bug fixed in 3.2 since every plug-in that changed in between I build have a different version number thanks to the .qualifier.
That satisfies me what with the new numbering schema.
per comments 33-35 i am closing this bug.
