Does that include a pull request against
https://github.com/paulp/version-investigator
Because honestly I'd rather never do any of this again.
I mention it because even the low ambition case is harder than it
looks, and it will be easier to get it right and keep it right if we
involve some code.
> SO, versioning:
>
> maven OSGi
> ---------- --------
> 2.9.2-SNAPSHOT 2.9.2-20100311-120-5deab6
> 2.9.2 2.9.2-20100401-132-a29e11
> 2.9.2-1 2.9.2-BUILD1-20101113-133-82e12a
None of those is a valid osgi version.
If the character after the 2.9.2 in each osgi case was intended to be
a . then they become valid versions, syntactically. But
2.9.2-SNAPSHOT comes before 2.9.2 in maven, and
2.9.2.20100311-120-5deab6 would come AFTER 2.9.2 in osgi. These are
the kinds of things version-inspector will tell you.
They are meant to be '.' And plain old 2.9.2 would never occur in the osgi version. That table was supposed to be my hand gobbled example from what I implemented in ant XML.
The idea is the maven-osgi versions are pairs referring to the same release.
The whole approach makes me pretty nervous. Can you elaborate it all
the way out? What are the equivalent OSGI versions for 2.10.0-M1,
2.9.1-1, etc? When there is a date in the name, what is that date? The
date the build was run? The git author date? The git committer date?
What time zone? Does building revision N+1 yesterday give a build
string which falls earlier or later than building revision N today?
Using the date string is to be the primary sorting key for every
development version will very likely go wrong. That's why git doesn't
do it, and uses distance from a reference commit.
There's not a lot of alphabet between DEV and FINAL, is the plan t
Thanks chrome, that was originally "There's not a lot of alphabet
between DEV and FINAL, is the plan to put everything including
milestones under DEV?"
On Tue, Mar 13, 2012 at 5:16 PM, Josh Suereth <joshua....@gmail.com> wrote:They are meant to be '.' And plain old 2.9.2 would never occur in the osgi version. That table was supposed to be my hand gobbled example from what I implemented in ant XML.
The idea is the maven-osgi versions are pairs referring to the same release.
On Mar 13, 2012 5:13 PM, "Paul Phillips" <pa...@improving.org> wrote:On Tue, Mar 13, 2012 at 11:27 AM, Josh Suereth <joshua....@gmail.com> wrote:
> No. I'm just using that to come up with versions that are closely related
> enough to appear to be the same, but also work in maven/osgi respectively.
I mention it because even the low ambition case is harder than it
looks, and it will be easier to get it right and keep it right if we
involve some code.
> SO, versioning:
>
> maven OSGi
> ---------- --------
> 2.9.2-SNAPSHOT 2.9.2-20100311-120-5deab6
> 2.9.2 2.9.2-20100401-132-a29e11
> 2.9.2-1 2.9.2-BUILD1-20101113-133-82e12a
None of those is a valid osgi version.
If the character after the 2.9.2 in each osgi case was intended to be
a . then they become valid versions, syntactically. But
2.9.2-SNAPSHOT comes before 2.9.2 in maven, and
2.9.2.20100311-120-5deab6 would come AFTER 2.9.2 in osgi. These are
the kinds of things version-inspector will tell you.
Yes. Milestones fall under dev. Dates are meant to always be UTC of build time, the middle number is the current git describe "# of commits since x" which should resolve timing issues.
Marking the version FINAL for releases move it into its own category where it immediately wins against any milestone/RC.
The maven versions just use canonical maven hackery to exhibit the same behavior.
Note: this scheme makes life easier if we stick to major-minor-bugfix versions. If we do build numbers again, it's mildly terrible for OSGi, although if we base the commit range on the same tag, we should be all good.
Note: if we translate our tags to lexicographically sorted strings with no '.'s I can use them too. I think I learned enough windows batch to make that happen. The downside is that this is usually a string quite close to major-minor-bugfix.
- Josh
Well R throws an issue in the alphabet. I was debating using EA for RC in osgi, so sorting is correct.
As for multiple builds on the same day, notice the commits since tag X in there. That should bump two builds on the same day since the one with more commits wins. That may not be ideal, but it seemed good as I was thinking things through.
I think you picked a better scheme here. I'll use this one.
Scala -version would return the OSGi version, since it gives us the most useful debugging info.
I think you picked a better scheme here. I'll use this one.
2.9.2 (final) -> 2.9.2.v0-<xxx>2.9.2-1 (final) -> 2.9.2.v1-<xxx>
201106241814
v20110823
v201101211721
20111221
v201101211617
v201103041518
v20120109-1030
v201101211617
v201012070820
v201101211617
v201101211721
v20100421-0704
v201101211721
v20100421-0704
v201101211721
20110613132200
v20120110-1739
I20110208-0800
R37x_v20111109-0800
v20100505
I20110111-0800
v20110423-0524
I20100824-0800
I20110222-0800
I20110111-0800
v20110228
v20111007_r372
v20110928-1504
v20110423-0524
v20120113-1953
I20110511-0800
v20120125-1505
v20110110
v20110505
v20100505
v20110110
v20110928-1503
v201202080800
v20111129-2031
v20111129-1423_r372
v20110531-2218
v20110321
v20110523
v20110502
R37x_v20110701
v20110502
v20110815-1438
v20110502
v20100503
v20110502
64_1.1.101.v20120109-1504
v20110502
v20110815-1419
v20120113-1346
v20111126-0153
v20111126-0211
v20110815-1419
R37x_v20111003
v20110815-1419
v20110815-1438
v20110815-1419
R37x_v20111111
v20110815-1438
v20110815-1419
v20120113-1346
v20110815-1438
v20120113-1346
v20110815-1419
v20111128-0624
R37x_v20111103
v20110815-1419
v20120113-1346
v20110815-1419
v20120111-2020
R37x_v20110810-1611
v20100503
R37x_v20110822-1018
v20101004
R37x_v20110822-1018
v20110815-1438
v20110502
v20110425
v201202080800
v20110426
r37_20110819
r37_20110929
v20110426
v20110420-1015
v20110305-1450
v0110816-0800
v_B79_R37x
v20110928-1453
v20120119-1537
v20111006_r372
v20120120-1417
r372_v20111103
v20110928-1453
v20111006_r372
v201202080800
v20120109-1427
v201202080800
I20100907-0800
v20110928-1505
v20111213-1208
v20110928-1505
I20110514-0800
R37x_v20111201-1600
r372_v20111101-0700
v20110928-1453
v20110513
v20120110-1415
v20110110
v20120110-1415
v20111129-2053
v20110803_r371
v20111129-2053
v20111116-2009
v20120103_r372
v20120120-1417
v20100601
v20111213-1754
v20110928-1516
v20110506
v20110928-1516
v201202080800
v20110516
v20120103_r372
v20110928-1516
v20120103_r372
v201202080800
v20120120-1417
r372_v20111202
v201202080800
v20110928-1504
64.source_3.7.2.v3740f
64_3.7.2.v3740f
v3740f
I20110525-0800
I20110510-0800
I20110511-0800
v20120126-1227
R37x_v20111109-0800
v20110928-1504
v20111019-1723
v20110425
I20101109-0800
v20111007_r372
v20110928-1504
v20111007_r372
v20111011-1919
I20110306-2000
v20110928-1505
v20110425
v20110510
v20110425
v20110928-1505
v20120106-1355
v20111208-1155
I20100517-1500
v20110928-1505
v20110404
v20110928-1505
I20110413-1600
v20120104-1859
v20110928-1504
v20120104-1859
v20110928-1505
v20100512
v20110330
v20100512
v20090501071000
v3_8_2_v20100427-1100
v4_8_2_v20110321-1705
v20100525
v3_8_2_v20100427-1100
v4_8_2_v20110321-1705
v201012071420
v201105211655
v20110329
That's another reason to follow the previous suggestion. I see no
reason to confuse everyone by displaying the osgi version anywhere
outside of osgi. Even lowly programmers, who will presumably
eventually figure out why we call it two different things, are worthy
of our sympathy.
Here are the unique fourth quadrants from the non-scala jars in my
eclipse folder. I'm thinking we ought to mimic what everyone else
does more closely in the osgi version, which means don't even bother
with "DEV" and "FINAL" and attempts to attach meaning and just
timestamp it. Let the maven version have the meanings.
So by "maven version" here we mean x.y.z-SNAPSHOT, yes?
To me this says unnamed development builds should go like this:
Canonical version, printed by scalac -version:
x.y.z-buildstring-with-githash-date-whatever
Maven version: x.y.z-SNAPSHOT
OSGI version: x.y.z.yyyymmddhhss
> At a minimum, I need the git hash.
We can of course append it to the osgi time snapshot, but what does
"need" mean in this context? You'll have access to it regardless, it
can and should be in the properties file. It can't be necessary for
ordering the builds since to-the-second timestamps aren't going to
leave much room for tiebreakers.
There's no reason it can't be in the osgi version if you need it, but
I'm resisting duplicating the information into more places than
necessary, and everything we add to the osgi version string represents
a point of future failure and/or difficulty in changing.
We should even have a command line option just to get the git hash, so
you can say
git log -n1 $(scalac -build-commit)
or whatever.
On Wed, Mar 14, 2012 at 7:41 AM, Josh Suereth <joshua....@gmail.com> wrote:So by "maven version" here we mean x.y.z-SNAPSHOT, yes?
> Well, remember the maven version does not include date, nor does it include
> git hash.
To me this says unnamed development builds should go like this:
Canonical version, printed by scalac -version:
x.y.z-buildstring-with-githash-date-whatever
Maven version: x.y.z-SNAPSHOT
OSGI version: x.y.z.yyyymmddhhss
We can of course append it to the osgi time snapshot, but what does
> At a minimum, I need the git hash.
"need" mean in this context?
You'll have access to it regardless, it
can and should be in the properties file.
It can't be necessary for
ordering the builds since to-the-second timestamps aren't going to
leave much room for tiebreakers.
There's no reason it can't be in the osgi version if you need it, but
I'm resisting duplicating the information into more places than
necessary, and everything we add to the osgi version string represents
a point of future failure and/or difficulty in changing.
We should even have a command line option just to get the git hash, so
you can say
git log -n1 $(scalac -build-commit)
or whatever.
But how likely is that? It gets to be more trouble to release a hotfix
than to go to the next bugfix release, particularly given the current
schedules on minor/bugfix releases.
Also, if ever that schedule becomes more sedate, one can go to the
double-digits hotfix version without backward compatibility problems,
since the major/minor/bugix version would take precedence.
--
Daniel C. Sobral
I travel to the future all the time.
OK, that's a good reason. So would .<timestamp>-<sha> suffice?
We should drop the 'g', too, as long as we're molding these things for
our own purposes. (For those unaware, git prepends the 'g' as a nod
to SCM-independence; it means "git".) I seriously question its
utility, but I also like to avoid deviating from defaults without just
cause.
On Wed, Mar 14, 2012 at 08:12, Mirco Dotta <mirco...@typesafe.com> wrote:2.9.2 (final) -> 2.9.2.v0-<xxx>2.9.2-1 (final) -> 2.9.2.v1-<xxx>And, if there are ever going to be more than nine "hotfix" releases, thenthis should be2.9.2 (final) -> 2.9.2.v00-<xxx>2.9.2-1 (final) -> 2.9.2.v01-<xxx>
But how likely is that? It gets to be more trouble to release a hotfix
than to go to the next bugfix release, particularly given the current
schedules on minor/bugfix releases.
Also, if ever that schedule becomes more sedate, one can go to the
double-digits hotfix version without backward compatibility problems,
since the major/minor/bugix version would take precedence.
+1 -- i've more than once wondered why i couldn't find the commit for my scalac build (until i remembered g is not in hex's alphabet)
On Wed, Mar 14, 2012 at 4:57 PM, Paul Phillips <pa...@improving.org> wrote:
We should drop the 'g', too, as long as we're molding these things for
our own purposes. (For those unaware, git prepends the 'g' as a nod
to SCM-independence; it means "git".) I seriously question its
utility, but I also like to avoid deviating from defaults without just
cause.
I need to be able to know, based on the version number that people see in their Eclipse installation details, if a certain commit is or is not in their build. Timestamps fix the ordering issues, but there's also some useful information that should be part of that qualifier.
I'm really worried about the idea of attaching timestamps of builds to version numbers. This way we make our builds non-reproducible which I learnt the hard way yesterday while working with Scala virtualized. I created a custom branch of scala with some patches attached, published scala to Maven repo locally and modified a bunch of my projects to depend on that version. I shared the result with Nada and it turned out that she has no way to reproduce my results even if she has all necessary branches checked out because scala builds are not reproducible.On 14 March 2012 16:42, iulian dragos <jagu...@gmail.com> wrote:I need to be able to know, based on the version number that people see in their Eclipse installation details, if a certain commit is or is not in their build. Timestamps fix the ordering issues, but there's also some useful information that should be part of that qualifier.
Since we switched to distributed version system we need to embrace an idea of distributed (reproducible!) builds as well. I know that in other contexts you have different needs and that's why I think "one size fits all" approach to version numbers is not going to get us anywhere.Based on all I read about version numbers I propose we come up with different versioning schemes serving different needs. I think we should start by identifying those, first.
--
Grzegorz Kossakowski
because scala builds are not reproducible.
I'm really worried about the idea of attaching timestamps of builds to version numbers. This way we make our builds non-reproducible which I learnt the hard way yesterday while working with Scala virtualized. I created a custom branch of scala with some patches attached, published scala to Maven repo locally and modified a bunch of my projects to depend on that version. I shared the result with Nada and it turned out that she has no way to reproduce my results even if she has all necessary branches checked out because scala builds are not reproducible.On 14 March 2012 16:42, iulian dragos <jagu...@gmail.com> wrote:I need to be able to know, based on the version number that people see in their Eclipse installation details, if a certain commit is or is not in their build. Timestamps fix the ordering issues, but there's also some useful information that should be part of that qualifier.
Because the next day you publish the same Git sha1 it's going to be published with different timestamp. You cannot reproduce yesterday results without tweaking your system clock or hacking build scripts.
-- Sent from Android
Guys we already have 3 numbers for different use cases.
(1) maven releases. If you want reproducible builds in maven don't use snapshots. They're broken.
(2) osgi releases. This version is designed so that compatible newer versions override older ones.
(3) our internal bugfix info. We can do whatever.
That's exactly the kind of thing I was afraid of when timestamps were
first mentioned. I'm "glad" to see it's actually a problem (only glad
in the sense that if it's going to be a problem, better to have a
concrete example now.)
Since we should be speaking in code, not words:
https://github.com/paulp/version-investigator
The following is NOT my proposal wrt versions. The point is to get us
speaking in code. Send me your pull requests.
bin/generateVersions 2.9.1 1 79e937bea2 20120314-0923
Outputs at this writing - strawman only - to be refined until
satisfactory to all:
Arguments:
"2.9.1"
"1"
"79e937bea2"
"20120314-0923"
Release:
canonical: 2.9.1-1-79e937bea2-20120314-0923
osgi: 2.9.1.20120314-0923-1-79e937bea2
maven: 2.9.1-1
Development:
canonical: 2.9.1-1-79e937bea2-20120314-0923
osgi: 2.9.1.20120314-0923-1-79e937bea2
maven: 2.9.1-1-SNAPSHOT
My pull request is on scala / scala. I still stand by what I had as no better or worse than any proposals I've seen.
Thanks
-- Martin
My pull request is on scala / scala. I still stand by what I had as no better or worse than any proposals I've seen.
agree. will the git committer date do (paul mentioned it before)? does it playwell with merges, linearizing history?lampmac1:scala luc$ git log --pretty=format:'%ct-%H' -n 11331486613-ee51b6e1b1bc4bd60e6f6bbaea6eb3d4be8b3c97
Any other suggestions? It's hard enough to come up with something that people agree, so please don't throw us back to square one without some proposal we can discuss. The requirements are simple enough: a scheme that increases monotonically using the OSGi rules, and that can behave reasonable with both snapshots and released versions.
Guys we already have 3 numbers for different use cases.
(1) maven releases. If you want reproducible builds in maven don't use snapshots. They're broken.
(2) osgi releases. This version is designed so that compatible newer versions override older ones.
(3) our internal bugfix info. We can do whatever.
git cherry-pick ruins having monotonically increasing dates IIRC. It preserves the date of the original commit, so merging patches between branches gets odd dates (by default).
I don't see immediately (after one day of pondering this) a reason why it wouldn't work.On 14 March 2012 17:25, Lukas Rytz <lukas...@epfl.ch> wrote:agree. will the git committer date do (paul mentioned it before)? does it playwell with merges, linearizing history?lampmac1:scala luc$ git log --pretty=format:'%ct-%H' -n 11331486613-ee51b6e1b1bc4bd60e6f6bbaea6eb3d4be8b3c97
Any other suggestions? It's hard enough to come up with something that people agree, so please don't throw us back to square one without some proposal we can discuss. The requirements are simple enough: a scheme that increases monotonically using the OSGi rules, and that can behave reasonable with both snapshots and released versions.What about a suggestion to take whatever has been proposed so far and just replace a timestamp coming from a machine running a build into a timestamp of a commit that is being built at the moment in UTC timezone?
Since we never force when pushing to scala/scala branches (like master or 2.9.x) we are going to have monotonically increasing timestamps guaranteed.I'll take Paul's advice and use his versioning tool but I'd like to know if anybody sees any obvious problem with this proposal?--
Grzegorz Kossakowski
What about a suggestion to take whatever has been proposed so far and just replace a timestamp coming from a machine running a build into a timestamp of a commit that is being built at the moment in UTC timezone?Sounds good! Thanks!
I'll take care of it this evening, as well as a 2.9.2-RC1 assuming everyone is in agreement.
Cheers
-- Martin
Echoing the long thread that followed, I just saw that article:
http://www.infoq.com/news/2012/04/osgi-snapshot
Scala developpers seems to not be alone with their numbering pain...
Cheers,
--
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com