[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] .qualifier for export package?
- From: "Chris Aniszczyk" <caniszczyk@xxxxxxxxx>
- Date: Sun, 31 Aug 2008 14:45:02 -0500
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=h0lChFm+bHzfYiv8i5fSiQQ6k866NjEomTgZ2qxcf1vig7jaYzvSh5sV21IHoQXIC9 NuWwk5QQzlQLQcPpiE4Z4nayke/MYbYUHHex9m/8UUOfvefBYrL0hSPDnTKTiEAd4+ZH m2Eg45Ag8JFuodnC8HKeFUbyWE4Sex+I/kqMI=
On Sun, Aug 31, 2008 at 5:53 AM, Jeff McAffer <jeff@xxxxxxxxx>
As version numbers on packages become more prevalent does it start making sense to use .qualifier on them in addition to bundle version numbers? The logic here is the same as for bundles. we rev the version number of the bundle to match the most extreme change for that release. in between if hte provisioning system is going to do its job, it needs to have different version numbers. Teh .qualifier allows for the auto-qualification of bundle version numbers. The same is true for folks using import/export package.
In PDE, I plan on releasing some builder logic to flag exported packages without versions with a warning in M2. API Tooling also has items in plan that deal with package versioning, but that will be post M2
Thoughts for how/if this should be introduced?
I say before M2, we formulate a plan across the Eclipse proper projects to deal with versions on package exports. We can than look at pushing that plan to other Eclipse.org projects as a best practice once we get the hang of it.
~ Chris Aniszczyk