Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Seeking opinions on timestamps in version strings

On Tue, Jan 5, 2016 at 12:22 PM, David M Williams <david_williams@xxxxxxxxxx> wrote:
Does this apply to every bundle you release? As you may know, we in the Eclipse Platform "prereq" some of your bundles from a p2 repository you create, and we would need 4 part version numbers in order to keep things straight. At least easily. For this exact case, I am not sure what implications/impact would be of "going down" (in terms of OSGi-like versions). That is, I am not sure if it just complicates things, or makes things impossible.

As far as I know, you only produce the p2 repository after you release something, so it may not be an issue. But, if that ever changed -- say, you wanted us to test something before it was released -- then I am pretty sure we would would not be able to do that with a 3-field release version.

I was curious about the OSGi version requirements too.


That indicates that on parsing, all segments are optional.
However, the .validate() method (line #182) shows that there's some segment value verification. (not negative numbers, only a limited scope of characters for qualifier, etc...)
No qualifier during parse results in a empty string "" definition on the Version.qualifier.

While VersionRange does have mention of qualifier.

It relies on Version.compareTo() for its logic, which treats qualifier via String.compareTo(String).
Which explains why you don't see qualifiers on Import definitions (not rigid enough to use for that kind of definition).

There are various groups within Eclipse that have attempted to work around this behavior of qualifier.
Some use "I", "R", or "v" at the start of a qualifier to indicate a stable release. (but even this is inconsistent, there's a few instances of "vI20070822" for example.)
Other groups use "#.#.#.vYYYYMMMDDHHSS-?" where "?" is the type of release (eg: "r" for release, "rc" for release candidate, "m" for milestone)
Other groups use "#.#.#.?" where "?" is the type of non-stable release (eg: "M" for milestone, "RC" for release candidate)
The larger majority of Eclipse projects have seemingly dropped qualifier entirely, which is what I'm soliciting feedback for in Jetty.

This inconsistency in various Eclipse projects makes the qualifier pretty much only useful for humans, not for definitions, code, auto-resolution, etc...

When you tackle the human angle, the meanings and expectations of the version string has evolved over the years.
5 years ago this wasn't a problem, but today we have more and more users comfortable with the non-osgi way.
The newer developers see a timestamp and go "oh, this is an unstable/milestone release, i'll avoid it."
And then see something like "9.3.0.RC0" and go "ooh, this one doesn't look like a milestone, lets use that one".

The desire for dropping timestamps is to make things simpler and less confusing for new users.
I suspect that for battle worn developers this isn't such a big deal.

- Joakim

Back to the top