Re: [jetty-dev] Seeking opinions on timestamps in version strings

["David M Williams" <david_williams@xxxxxxxxxx>]

> Can you detail a bit more about this 4 part version
number requirement ?

I could write pages and pages on the
topic ... at the same time, I am probably not the best authority. But that
has never stopped me before. :) 

Some detail about "the qualifier"
is documented in 
https://wiki.eclipse.org/index.php/Version_Numbering#When_to_change_the_qualifier_segment

Its primary purpose is related to process.
So that "months in advance" teams can produce things with the
yet-to-be-released number (such as 4.5.2). This allows consumers that are
testing early to put a requirement on that future release (such as they
need a fix or new API that is only in that future release of 4.5.2).  Since
those earlier testers and others may be "updating" or "installing"
from a large pool of bundles -- and often doing so weekly -- a way was
needed to distinguish one "build" from another. Technically,
of course the 3rd segment could be incremented each build, but that get's
to be kind of confusing and burdensome. Hence, the "qualifier"
was added by Eclipse and OSGi as a fourth field, with the only requirement
that it increases lexicographically from one build to the next  (if
there are changes).  Additional "cues" are often added that
are meant more for human's reading the qualifier, such as to distinguish
particular streams or type of build. Dates are often used as "the
core" part of qualifier simply because that's handy and easy to automate
and still meet the "lexicographically increasing" requirement
(for example, can often be the "last time" something was committed
to Git or CVS).  For simplicity, many teams use "date of build"
as the core part of the qualifier, but that's not ideal if "nothing
has changed".  

There as other, maybe more minor reasons
to use the 'qualifier' in the Eclipse process -- for example, during "support"
periods, it is good to confirm a client is using the final "released"
version of a bundle (as shown by the qualifier) plus,  a "patch"
can be applied (for one bundle) that has the exact same version, but an
incremented qualifier. (The "next service field number" would
have already been used by some other release). 

Given the above, 3 fields can not be
used for the "release" since "4.5.2.anything" is greater
than "4.5.2" so something with only "4.5.2" as the
version would not be installed (or ran) over something which already had
"4.5.2.anything" installed. Note: in OSGI the first three segments
need to be proper integers, only the 4th qualifier field is interpreted
as a string. 

For the Eclipse yearly Simultaneous
Release it is required that participants use a 4 part version identifier
because we want to allow and encourage others to "integrate often"
and use the latest of other's as-of-yet-not-released builds.  (And
that includes 70 or so projects and thousands of bundles, so not sure what
Joakim meant by  "The larger majority of Eclipse projects have
seemingly dropped qualifier entirely". That is just not true.) 

If Jetty intends to be a "proper
Eclipse/OSGi project" (that OSGi/p2 consumers can use before the release)
I would recommend using 4 part versions. And it does not have to be "dates".
If it helped your "new users" that were mentioned, you could
use ".RELEASE" for your final qualifier if that word was "larger
than" (lexicographically) anything you used during development of
that version. To be truthful, the reason we in the Platform do not do that,
is we often produce what we think is going to be our final build, and a
day or two later (before the official release day) someone finds a bad
regression and we have to rebuild. So it is easier, for us, to just stick
with the 'date' for the core qualifier rather than to have a special word.

I do not mean to be argumentative --
I am well aware this is a complex and confusing area and I am well aware
of the long history of several "camps" that have their own strong
points of view. I appreciate being able to express my point of view.  We
do not need to go over all the "Maven versioning" vs. "OSGi
versioning" arguments that have taken place for years and I am sure
there are counter points to many of my comments above that do not have
to be re-hashed. I am primarily trying to describe "how things currently
are" at Eclipse. 

Other references: 
Authoritative reference on Semantic
Versioning (which goes way beyond this discussion of just the qualifier
field): 
http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf

Historically the 128 comments that gave rise to Eclipse's
solution in 2006 on how to stop using only 3 fields during development.
Bug 99393- On the PRETTY BAD practice of NOT VERSIONING Eclipse. 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=99393

Hope this reply is helpful, 

Thanks, 







From:      
 Simone Bordet <sbordet@xxxxxxxxxxx>
To:      
 "Jetty @ Eclipse
developer discussion list" <jetty-dev@xxxxxxxxxxx>, 
Date:      
 01/05/2016 02:52 PM
Subject:    
   Re: [jetty-dev]
Seeking opinions on timestamps in version strings
Sent by:    
   jetty-dev-bounces@xxxxxxxxxxx

---

Hi,

On Tue, Jan 5, 2016 at 8: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.

Can you detail a bit more about this 4 part version number requirement
?
Why do you need it ? Why it is 4 and not 3 or 5 ?
What would break if the version format changes ?

I'm not saying it's bad, I am just curious of what requisite you have
that would make a change in the version scheme make things harder for
you.
The more detailed use cases we have from the community, the more
information we have to make educated choices.

Thanks !

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev