Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between pages "Talk:Callisto Coordinated Update Sites" and "Callisto Build and Update Tips and Tricks"

(Difference between pages)
(commented on the comments (not sure how to best do that with wike))
 
 
Line 1: Line 1:
My comments (Kim Moir platform-releng) :-)
+
On this page, please add any little tidbits that help with the versioning, site management, etc., that are not part of other documents.
  
(1)There is a problem with the url
 
http://update.eclipse.org/updates/callisto/
 
  
Currently, the platform team stores all its updates in this directory
+
=== Automatically versioning features appropriately ===
  
http://update.eclipse.org/updates
+
I haven't tried it yet, but in
 +
[[https://bugs.eclipse.org/bugs/show_bug.cgi?id=125801#c9 | bug 125801]
 +
Andrew Niefer mentions that
  
and subdirectories such as these
+
<p><cite>
 +
When using ".qualifier", the resulting feature version can take the form of
 +
1.2.3.qualifier_suffix, where qualifier will come from the cvs tag, or date the
 +
same as for plugins.  suffix will be generated based on the qualifiers of the
 +
contained plugins.
 +
<br /><br />
 +
Whether or not to append the _suffix to the version is controlled by the
 +
property "generateFeatureVersionSuffix" in the builder's build.properties.  The
 +
default value is false.
 +
</cite>
 +
</p>
  
http://update.eclipse.org/updates/3.0
+
I personally feel that <code>generateFeatureVersionSuffix</code> should be the default, but since it isn't, thought I'd document here.  
http://update.eclipse.org/updates/3.1
+
  
So I don't know that this is the best url for Callisto
+
This is important since a feature's qualifier needs to not just change accourding to its own changes, but also needs to reflect the "most changed" plugin it contains.
  
http://update.eclipse.org/updates/callisto/
+
=== Do not use underscore in version qualifiers ===
  
given that
+
I think this will all work better post M5, but certainly on 3.1.x streams, and underscore is converted to a hyphen in some places, and will at first seeem to work, but then there's problems associating source with its code, etc., so ... use with care, if not outright avoid. See [[https://bugs.eclipse.org/bugs/show_bug.cgi?id=89428 | bug 89428]] for some dicussions.
we already have platform content in that directory
+
we can't change the Apache alias for platform because this has been hardcoded in our feature.xmls
+
the unix permissions on the directory mean that the platform team would need to retain ownership in order to continue update the content in the existing update sites.
+
  
[dmw: agreed, we should have 'callisto' first in the URL, and keep it "parallel" other Eclipse projects]
+
=== Use the platform releng tool ===
  
 +
To update your map files automatically while releasing your plug-ins, the releng tool found as a download way at the bottom of the platform download page is quite helpful.  The instructions are sparse, but it's fairly straightforward (right-click a project and select Team -> Release...).
  
(2)Providing Callisto as a single download comprising all 10 projects provides better exposure to the newer projects. By the same token, it also forces people to download stuff that they may not necessarily want or ever use, thus significantly increasing the strain on the distribution infrastructure. It is also rather overwhelming for a new eclipse user.  My point is, perhaps there is a better way to educate users and provide choice while simultaneously exposing the full breadth of functionality available with Callisto.
+
When using .qualifier at the end of your Bundle-Version manifest entries, your plug-ins will be versioned according to the tags entered in your map files automatically when using the release engineering tool with the PDE basebuilder.
  
[dmw: yep, this is the question to be answered empiracally and via community feedback ... but if we get one packaging working ... a few others should be easy --- though, I'd never want to get to the point of a Callisto user having more than, say, 4 or 5 choices ... those users that want more fine grained control than that will have to use project update URLs]
+
=== Guide to understanding versioning ===
 +
 
 +
Just because this page cannot be linked enough, look here for detailed information on when and how to apply new version numbers to your plug-ins and features: [[http://www.eclipse.org/eclipse/platform-core/documents/plugin-versioning.html Plug-in Versioning]]

Revision as of 12:37, 24 February 2006

On this page, please add any little tidbits that help with the versioning, site management, etc., that are not part of other documents.


Automatically versioning features appropriately

I haven't tried it yet, but in [| bug 125801 Andrew Niefer mentions that

When using ".qualifier", the resulting feature version can take the form of 1.2.3.qualifier_suffix, where qualifier will come from the cvs tag, or date the same as for plugins. suffix will be generated based on the qualifiers of the contained plugins.

Whether or not to append the _suffix to the version is controlled by the property "generateFeatureVersionSuffix" in the builder's build.properties. The default value is false.

I personally feel that generateFeatureVersionSuffix should be the default, but since it isn't, thought I'd document here.

This is important since a feature's qualifier needs to not just change accourding to its own changes, but also needs to reflect the "most changed" plugin it contains.

Do not use underscore in version qualifiers

I think this will all work better post M5, but certainly on 3.1.x streams, and underscore is converted to a hyphen in some places, and will at first seeem to work, but then there's problems associating source with its code, etc., so ... use with care, if not outright avoid. See [| bug 89428] for some dicussions.

Use the platform releng tool

To update your map files automatically while releasing your plug-ins, the releng tool found as a download way at the bottom of the platform download page is quite helpful. The instructions are sparse, but it's fairly straightforward (right-click a project and select Team -> Release...).

When using .qualifier at the end of your Bundle-Version manifest entries, your plug-ins will be versioned according to the tags entered in your map files automatically when using the release engineering tool with the PDE basebuilder.

Guide to understanding versioning

Just because this page cannot be linked enough, look here for detailed information on when and how to apply new version numbers to your plug-ins and features: [Plug-in Versioning]

Back to the top