| OSGi versioning for the curious | Josh Suereth | 3/13/12 5:37 AM | http://wiki.eclipse.org/Version_Numbering If you read the above document, you'll see how our version schemes are not cool for OSGi. In particular, we use our first number (2) to Denote the "era" of scala. Granted, their 'minor' version number distinction is pretty vague.
In any case, if you're using OSGi, in the future, you should be able to make use of the following knowledge: <major>.<minor>.<bugfix>.<qualifier>
<major> - Denotes our Epoch of Scala. Major language change from 1.x to 2.x to 3.x. <minor> - Denotes binary incompatible API and/or incremental language changes <bugfix> - Denotes bug fixes that should not break the external/binary API
<qualifier> - lexicographically increasing number used to release snapshots during development. I'm attempting to stuff GIT information into the <qualifier>, but in a lexicographically increasing way. Anyone have any suggestions (that work with OSGi), let me know. Otherwise I'll link to my pull request once my mechanism works.
Thanks! - Josh
|
| Re: [scala-internals] OSGi versioning for the curious | Paul Phillips | 3/13/12 10:43 AM | On Tue, Mar 13, 2012 at 5:37 AM, Josh Suereth <joshua....@gmail.com> wrote: Does that include a pull request against https://github.com/paulp/version-investigator Because honestly I'd rather never do any of this again. |
| Re: [scala-internals] OSGi versioning for the curious | Josh Suereth | 3/13/12 11:27 AM | 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. We'll have two version numbers. psuedo code ->
val osgiString = Path("tools/get-scala-version").!! // Note this is different in my branch. val osgiVersion = maven version match {
case something + "-SNAPSHOT" => something + "-" + osgiString case something + "-" + number => something + "-BUILD-" + number + "-" + osgiString
case something => something + "-" + osgiString }
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 Unless my brain is still toast from last week, it appears to have all the properties we want in version numbers *and* should also be useful. Note: The OSGi version number will be printed by scalac when run, since it has the most information.
Thoughts?
|
| Re: [scala-internals] OSGi versioning for the curious | Odd Möller | 3/13/12 11:59 AM | Shouldn't the fact that a Scala installation was built from a snapshot version (as opposed to from a final one) be reflected in the version string returned by "scala -v"? Greetings //Odd |
| Re: [scala-internals] OSGi versioning for the curious | Josh Suereth | 3/13/12 12:47 PM | For the purposes of reporting bugs and finding errors, I don't see how that extra information helps us terribly. I can certainly add an "R" at the beginning of the version string for releases. What purpose do you see for such a notation? |
| Re: [scala-internals] OSGi versioning for the curious | Odd Möller | 3/13/12 1:12 PM | Mainly as a way to quickly get a sense of the stability of the installed Scala version when encountering problems (with the assumption that the final builds are in some respect of higher quality). If the version used is a snapshot version, an upgrade to a later version could be attempted, but if it is a final version the problem probably lies elsewhere. //Odd |
| Re: [scala-internals] OSGi versioning for the curious | Paul Phillips | 3/13/12 2:13 PM | On Tue, Mar 13, 2012 at 11:27 AM, Josh Suereth <joshua....@gmail.com> wrote: I mention it because even the low ambition case is harder than it > SO, versioning: None of those is a valid osgi version. If the character after the 2.9.2 in each osgi case was intended to be |
| Re: [scala-internals] OSGi versioning for the curious | Josh Suereth | 3/13/12 2:16 PM | 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. |
| Re: [scala-internals] OSGi versioning for the curious | Josh Suereth | 3/13/12 9:57 PM | Ok, so it looks to be passing Paul's version inspector. Here's the new output of init: Nightlies --
ant init init: [echo] build time: 14 March 2012, 00:52:07
[echo] java version: OpenJDK 64-Bit Server VM 1.6.0_23 [echo] java args: -Xms1536M -Xmx1536M -Xss1M -XX:MaxPermSize=192M -XX:+UseParallelGC
[echo] javac args: [echo] scalac args: [echo] maven version: 2.9.2-SNAPSHOT
[echo] OSGi version: 2.9.2.DEV-20120314-0175-gb8b51b70b RCs --
ant -Dmaven.version.suffix=-RC1 init init: [echo] build time: 14 March 2012, 00:53:58
[echo] java version: OpenJDK 64-Bit Server VM 1.6.0_23 [echo] java args: -Xms1536M -Xmx1536M -Xss1M -XX:MaxPermSize=192M -XX:+UseParallelGC
[echo] javac args: [echo] scalac args: [echo] maven version: 2.9.2-RC1
[echo] OSGi version: 2.9.2.DEV-20120314-0175-gb8b51b70bf FINAL releases
ant -Dbuild.release=true init init: [echo] build time: 14 March 2012, 00:53:07
[echo] java version: OpenJDK 64-Bit Server VM 1.6.0_23 [echo] java args: -Xms1536M -Xmx1536M -Xss1M -XX:MaxPermSize=192M -XX:+UseParallelGC [echo] javac args:
[echo] scalac args: [echo] maven version: 2.9.2 [echo] OSGi version: 2.9.2.FINAL-20120314-0175-gb8b51b70bf Anyone against? |
| Re: [scala-internals] OSGi versioning for the curious | Paul Phillips | 3/14/12 1:56 AM | On Tue, Mar 13, 2012 at 9:57 PM, Josh Suereth <joshua....@gmail.com> wrote: > Anyone against? The whole approach makes me pretty nervous. Can you elaborate it all There's not a lot of alphabet between DEV and FINAL, is the plan t |
| Re: [scala-internals] OSGi versioning for the curious | Paul Phillips | 3/14/12 1:56 AM | On Wed, Mar 14, 2012 at 1:56 AM, Paul Phillips <pa...@improving.org> wrote: Thanks chrome, that was originally "There's not a lot of alphabet |
| Re: [scala-internals] OSGi versioning for the curious | Iulian Dragos | 3/14/12 3:44 AM | Josh, thanks a lot for putting this together. It looks good to me. I'd add the time to the timestamp, since there may be more than one build published in a day (there have been cases when we needed a bugfix in the compiler, and pick it up in a subsequent IDE build) -- or maybe the 'git describe' string coming afterwards takes care of that?
I'm not so worried about using a timestamp there, because anything that gets published under org.scala-lang should be built by the EPFL Jenkins jobs. Timestamps are standard practice in OSGi AFAICT, including the release version of Eclipse SDK (for instance: 3.7.1.M20110909-1335).
I am a bit disappointed the RC1 would be gone in the OSGi version. What would 'scala -v' show for 2.9.2-RC1? cheers, iulian
« Je déteste la montagne, ça cache le paysage » Alphonse Allais |
| Re: [scala-internals] OSGi versioning for the curious | Mirco Dotta | 3/14/12 3:46 AM | Hi Josh, I'm a bit worried about what will happen to people that currently have Scala IDE 2.0.0 installed. The compiler.jar we currently package with the Scala IDE 2.0.0 has the following version 2.9.2.rdev-2769-2011-12-13-g2dd83da. If we ship a maintenance release of the Scala IDE with 2.9.2 final and the proposed OSGi versioning scheme, I'm not sure what are the consequences. My main concern is that 2.9.2.FINAL-<xxx> < 2.9.2.rdev-<xxx>, and hence it could be possible that when upgrading the Scala IDE, the old compiler jar (2.9.2.rdev-) will be used instead of the new one. Unfortunately, my understanding of how Eclipse handles upgrade is not as clear as it should be. I'll try to document myself and provide more information about this point if I manage to find them. One more thing: What will it be the answer of `scala -v`? The maven version? The OSGi one? Neither of them? It would be useful if the OSGi version and `scala -v` could provide very similar answers, so that from one you can easily derive the other. Here is my suggestion for versioning (which I still need to validate against Paul's version-investigator): Maven -> OSGi 2.9.2-SNAPSHOT -> 2.9.2.dev-<xxx> 2.9.2-M1-> 2.9.2.m1-<xxx> 2.9.2-RC1-> 2.9.2.rc1-<xxx> 2.9.2 (final) -> 2.9.2.v0-<xxx> 2.9.2-1 (final) -> 2.9.2.v1-<xxx> Where the <xxx> is monotonically increasing at every build (independently of where the build is actually executed, i.e., time needs to be absolute). But I'm missing what is the answer of `scala -v`. -- Mirco --------------- Mirco Dotta Typesafe - The software stack for applications that scale PSE-D, 1015 Lausanne, Switzerland Work: +41 (0)21 691 49 65 Twitter: @mircodotta |
| Re: [scala-internals] OSGi versioning for the curious | Josh Suereth | 3/14/12 3:49 AM | 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 |
| Re: [scala-internals] OSGi versioning for the curious | Josh Suereth | 3/14/12 3:52 AM | 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. |
| Re: [scala-internals] OSGi versioning for the curious | Josh Suereth | 3/14/12 3:54 AM | 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. |
| Re: [scala-internals] OSGi versioning for the curious | Mirco Dotta | 3/14/12 4:03 AM |
Actually, I'm now wondering about 2.9.2.m1-<xxx> > 2.9.2.dev-<xxx>, which may or may not be ideal. WDYT? |
| Re: [scala-internals] OSGi versioning for the curious | Mirco Dotta | 3/14/12 4:12 AM |
And, if there are ever going to be more than nine "hotfix" releases, then this should be 2.9.2 (final) -> 2.9.2.v00-<xxx> 2.9.2-1 (final) -> 2.9.2.v01-<xxx> |
| Re: [scala-internals] OSGi versioning for the curious | √iktor Klang | 3/14/12 4:15 AM | Semantics in version identifiers is so bad it hurts my intellect.-- Viktor Klang Akka Tech Lead Typesafe - The software stack for applications that scaleTwitter: @viktorklang |
| Re: [scala-internals] OSGi versioning for the curious | Josh Suereth | 3/14/12 6:35 AM | So with my patches, this is what starting scala 2.9.2-RC1 may look like: Welcome to Scala version 2.9.2.dev-20120314-0178-ga8b5d8a349(2.9.2-RC1) (OpenJDK 64-Bit Server VM, Java 1.6.0_23). 2012/3/14 √iktor Ҡlang <viktor...@gmail.com> |
| Re: [scala-internals] OSGi versioning for the curious | Paul Phillips | 3/14/12 7:29 AM | 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.
|
| Re: [scala-internals] OSGi versioning for the curious | Paul Phillips | 3/14/12 7:34 AM | On Wed, Mar 14, 2012 at 3:54 AM, Josh Suereth <joshua....@gmail.com> wrote: That's another reason to follow the previous suggestion. I see no |
| Re: [scala-internals] OSGi versioning for the curious | √iktor Klang | 3/14/12 7:39 AM | *applause* :-) |
| Re: [scala-internals] OSGi versioning for the curious | Josh Suereth | 3/14/12 7:41 AM | Well, remember the maven version does not include date, nor does it include git hash. How bout I simplify the OSGi version and still show both?
|
| Re: [scala-internals] OSGi versioning for the curious | Iulian Dragos | 3/14/12 8:09 AM | On Wed, Mar 14, 2012 at 3:29 PM, Paul Phillips <pa...@improving.org> wrote: Here are the unique fourth quadrants from the non-scala jars in my That's not very helpful. At a minimum, I need the git hash. Ideally, something similar enough (after the timestamp) to what `scala -v` says. The timestamp ensures increasing version numbers, so we can put what `scala -v` says afterwards (the current scheme, `git --described` looks good).
cheers, iulian |
| Re: [scala-internals] OSGi versioning for the curious | Paul Phillips | 3/14/12 8:32 AM | On Wed, Mar 14, 2012 at 7:41 AM, Josh Suereth <joshua....@gmail.com> wrote: > Well, remember the maven version does not include date, nor does it include > git hash. 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: > At a minimum, I need the git hash. We can of course append it to the osgi time snapshot, but what does There's no reason it can't be in the osgi version if you need it, but We should even have a command line option just to get the git hash, so git log -n1 $(scalac -build-commit) or whatever. |
| Re: [scala-internals] OSGi versioning for the curious | Iulian Dragos | 3/14/12 8:42 AM | On Wed, Mar 14, 2012 at 4:32 PM, Paul Phillips <pa...@improving.org> 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.
Not sure how, short of unzipping the jar. I think that would make it way too difficult for people to report meaningful bugs, or even for myself when debugging an issue.
thanks, iulian
« Je déteste la montagne, ça cache le paysage » Alphonse Allais |
| Re: [scala-internals] OSGi versioning for the curious | Daniel Sobral | 3/14/12 8:55 AM | 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, then > this should be > > 2.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 Also, if ever that schedule becomes more sedate, one can go to the > -- I travel to the future all the time. |
| Re: [scala-internals] OSGi versioning for the curious | Paul Phillips | 3/14/12 8:57 AM | On Wed, Mar 14, 2012 at 8:42 AM, iulian dragos <jagu...@gmail.com> wrote: 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 |
| Re: [scala-internals] OSGi versioning for the curious | Mirco Dotta | 3/14/12 9:02 AM |
Hi Daniel, Yes, I guess I was being overcautious. Anyway, now I am of the idea it is better to adopt a scheme where build numbers are not meaningful for ordering, i.e., 2.9.2.vYYYYHHMM-XXX where XXX can be anything that provides enough information to a user to understand what Scala version is linked to. |
| Re: [scala-internals] OSGi versioning for the curious | Adriaan Moors | 3/14/12 9:01 AM | +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) |
| Re: [scala-internals] OSGi versioning for the curious | Mirco Dotta | 3/14/12 9:03 AM | +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) +10! I'm glad I wasn't the only one :)
|
| Re: [scala-internals] OSGi versioning for the curious | Grzegorz Kossakowski | 3/14/12 9:15 AM | 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. 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 |
| Re: [scala-internals] OSGi versioning for the curious | Iulian Dragos | 3/14/12 9:24 AM | On Wed, Mar 14, 2012 at 5:15 PM, Grzegorz Kossakowski <grzegorz.k...@gmail.com> wrote: 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.
thanks, iulian
|
| Re: [scala-internals] OSGi versioning for the curious | Adriaan Moors | 3/14/12 9:25 AM | On Wed, Mar 14, 2012 at 5:15 PM, Grzegorz Kossakowski <grzegorz.k...@gmail.com> wrote: because scala builds are not reproducible. |
| Re: [scala-internals] OSGi versioning for the curious | Lukas Rytz | 3/14/12 9:25 AM | On Wed, Mar 14, 2012 at 17:15, Grzegorz Kossakowski <grzegorz.k...@gmail.com> wrote: agree. will the git committer date do (paul mentioned it before)? does it play well with merges, linearizing history? lampmac1:scala luc$ git log --pretty=format:'%ct-%H' -n 1
1331486613-ee51b6e1b1bc4bd60e6f6bbaea6eb3d4be8b3c97
|
| Re: [scala-internals] OSGi versioning for the curious | Grzegorz Kossakowski | 3/14/12 9:33 AM | 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 |
| Re: [scala-internals] OSGi versioning for the curious | Josh Suereth | 3/14/12 9:34 AM | 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. |
| Re: [scala-internals] OSGi versioning for the curious | Paul Phillips | 3/14/12 9:44 AM | On Wed, Mar 14, 2012 at 9:33 AM, Grzegorz Kossakowski That's exactly the kind of thing I was afraid of when timestamps were 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 bin/generateVersions 2.9.1 1 79e937bea2 20120314-0923 Outputs at this writing - strawman only - to be refined until Arguments: Release: Development: |
| Re: [scala-internals] OSGi versioning for the curious | Josh Suereth | 3/14/12 11:24 AM | 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. |
| RE: [scala-internals] OSGi versioning for the curious | Chris Marshall | 3/15/12 10:32 AM |
In the InfoQ interview [1] Martin said "Scala currently breaks binary compatibility with major releases. Minor releases have been binary compatible for a while now" (unless misquoted). It would have sounded less impressive as "bugfix releases have been binary compatible for a while now" Chris [1] (
http://www.infoq.com/articles/odersky-scala-interview ) From: joshua....@gmail.com Date: Tue, 13 Mar 2012 08:37:26 -0400 Subject: [scala-internals] OSGi versioning for the curious To: scala-i...@googlegroups.com http://wiki.eclipse.org/Version_Numbering If you read the above document, you'll see how our version schemes are not cool for OSGi. In particular, we use our first number (2) to Denote the "era" of scala. Granted, their 'minor' version number distinction is pretty vague.
In any case, if you're using OSGi, in the future, you should be able to make use of the following knowledge: <major>.<minor>.<bugfix>.<qualifier>
<major> - Denotes our Epoch of Scala. Major language change from 1.x to 2.x to 3.x. <minor> - Denotes binary incompatible API and/or incremental language changes <bugfix> - Denotes bug fixes that should not break the external/binary API
<qualifier> - lexicographically increasing number used to release snapshots during development. I'm attempting to stuff GIT information into the <qualifier>, but in a lexicographically increasing way. Anyone have any suggestions (that work with OSGi), let me know. Otherwise I'll link to my pull request once my mechanism works.
Thanks! - Josh |
| Re: [scala-internals] OSGi versioning for the curious | Josh Suereth | 3/15/12 10:39 AM | bugfix releaseas *are* minor releases for scala. We take the four version approach: <2>.<major>.<minor>-<bugfix> Where 2 means "Written in Scala" and 3 might mean "New typesystem".
- Josh
|
| Re: [scala-internals] OSGi versioning for the curious | martin | 3/15/12 10:57 AM | On Thu, Mar 15, 2012 at 6:32 PM, Chris Marshall <oxbow...@hotmail.com> wrote:Minor releases are not bugfix releases. We do add library functionality in them, but make sure we stay binary compatible. This is a hard problem, and we have poured considerable resources in assuring binary compatibility. It would be nice to see this appreciated by the community instead of being belittled. Thanks -- Martin |
| Re: [scala-internals] OSGi versioning for the curious | Grzegorz Kossakowski | 3/15/12 11:17 AM |
Josh, I guess you are talking about: This pull requests affects 2.9.x and not master. Am I correct that you would like to get those changes cherry-picked for master as well? Grzegorz Kossakowski |
| Re: [scala-internals] OSGi versioning for the curious | Grzegorz Kossakowski | 3/15/12 11:33 AM | I don't see immediately (after one day of pondering this) a reason why it wouldn't work.
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 |
| Re: [scala-internals] OSGi versioning for the curious | Josh Suereth | 3/15/12 11:33 AM | Yes. However, for now I need to update 2.9.x branch so I can release RC1 |
| Re: [scala-internals] OSGi versioning for the curious | Josh Suereth | 3/15/12 11:35 AM | 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). |
| Re: [scala-internals] OSGi versioning for the curious | Grzegorz Kossakowski | 3/15/12 11:37 AM | On 14 March 2012 17:34, Josh Suereth <joshua....@gmail.com> wrote: I agree. That's why I switched from 2.10.0-virtualized-SNAPSHOT version to something like
"2.10.0-M2-0020-geab3b7e4d7-2012-03-06 " and used ant deploy.release.local for deploying to local Maven repo. I'd be happy with such a version (or any permutation of it's segments that satisfies osgi) as long as the whole version depends on info from Git repo and not on machine settings it's been ran on.
Grzegorz Kossakowski |
| RE: [scala-internals] OSGi versioning for the curious | Chris Marshall | 3/15/12 11:50 AM |
No-one was belittling anything. I was pointing out, in my usual ham-fisted way, that what you stated was in apparent contradiction with Josh's statement of what scala build number meant. Quoting Josh again:
To me, this says that 2 is a major version and 10 is a minor version; so now I am confused about which is which Chris > From: martin....@epfl.ch > Date: Thu, 15 Mar 2012 18:57:31 +0100 > Subject: Re: [scala-internals] OSGi versioning for the curious > To: scala-i...@googlegroups.com > |
| Re: [scala-internals] OSGi versioning for the curious | Grzegorz Kossakowski | 3/15/12 11:50 AM | On 15 March 2012 19:35, Josh Suereth <joshua....@gmail.com> wrote: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). Not really, that's why I proposed using git commit timestamp and not git author timestamp. Let me illustrate with an example:
eduroam-10-20-6-9:git-times grek (master)$ git log master --format=fuller commit 86280488f6d1f91bbaa68156c6c7f47d04238bfc Author: Grzegorz Kossakowski <grzegorz.k...@gmail.com>
AuthorDate: Thu Mar 15 19:41:43 2012 +0100 Commit: Grzegorz Kossakowski <grzegorz.k...@gmail.com> CommitDate: Thu Mar 15 19:41:43 2012 +0100
bar [...] eduroam-10-20-6-9:git-times grek (master)$ git log otherbranch --format=fuller commit f3169ceeae5e4c90586844f65381527cd3ebd4b1
Author: Grzegorz Kossakowski <grzegorz.k...@gmail.com> AuthorDate: Thu Mar 15 19:41:43 2012 +0100 Commit: Grzegorz Kossakowski <grzegorz.k...@gmail.com>
CommitDate: Thu Mar 15 19:42:08 2012 +0100 bar [...] What I did here was cherrypicking bar commit to other branch. As you can see in the original commit both AuthorDate and CommitDate were the same. However, once I cherry-picked the commit AuthorDate has been kept (Git always keeps it) and CommitDate has been updated because Git was really creating a new commit object.
The same distinction is preserved when you do rebasing. So when you rebase your commits they will keep original AuthorDate but will get CommitDate updated. AFAIK, we are safe on this front.
Grzegorz Kossakowski |
| Re: [scala-internals] OSGi versioning for the curious | Josh Suereth | 3/15/12 11:52 AM | AHHH, k. I get those confused *all the time*. |
| Re: [scala-internals] OSGi versioning for the curious | Josh Suereth | 3/15/12 11:59 AM | Right, so there's a debate of what *we scala developers* consider a major version, vs. the "canonical" "put digits here for this value" enforcement of maven/osgi. We ignore Maven OSGi in favor of marketing. Lots of folks do it. IF you look below, that's the mapping from *maven* version requirements to what they mean in Scala.
2.9 -> 2.10 is considered a major release for Scala. 2.9.0 -> 2.9.1 is considered a minor release. 2.9.1 -> 2.9.1-1 is considered a bugfix release.
You see, the versioning scheme is one size fits all, and the Scala versions were in place long before the scheme was forced on us all. - Josh
|
| Re: [scala-internals] OSGi versioning for the curious | Iulian Dragos | 3/15/12 1:49 PM | On Thu, Mar 15, 2012 at 7:33 PM, Grzegorz Kossakowski <grzegorz.k...@gmail.com> wrote: Sounds good! Thanks!
|
| Re: [scala-internals] OSGi versioning for the curious | Grzegorz Kossakowski | 3/15/12 2:01 PM | On 15 March 2012 21:49, iulian dragos <jagu...@gmail.com> wrote: It looks like we have an agreement, right? :-) Josh, Grzegorz Kossakowski |
| Re: [scala-internals] OSGi versioning for the curious | Josh Suereth | 3/15/12 2:05 PM | I'll take care of it this evening, as well as a 2.9.2-RC1 assuming everyone is in agreement. On Mar 15, 2012 5:01 PM, "Grzegorz Kossakowski" <grzegorz.k...@gmail.com> wrote:
|
| Re: [scala-internals] OSGi versioning for the curious | martin | 3/15/12 2:11 PM | On Thu, Mar 15, 2012 at 7:50 PM, Chris Marshall <oxbow...@hotmail.com> wrote:9/10 is the major version. 2 is the "epoch" i.e. the version of Scala we are all using. It's similar to Python or Java. Python 3 is incompatible in some profound ways with Python 2. If there will ever be a Scala 3 it will be the same. Java's official version is 1.7, i.e. 1 is still the language version. Cheers -- Martin |
| Re: [scala-internals] OSGi versioning for the curious | Josh Suereth | 3/15/12 10:19 PM | Ok, my 2.9.x pull request is updated with the results of this thread. Anyone want to take a look? |
| Re: [scala-internals] OSGi versioning for the curious | fanf | 4/5/12 6:50 AM | On 13/03/2012 13:37, Josh Suereth wrote:> [...] Echoing the long thread that followed, I just saw that article: Scala developpers seems to not be alone with their numbering pain... Cheers, -- |