[Pharo-project] Semantic Versioning
Do you guys know about this? This seems like it could fit really well with Metacello... http://semver.org/ Excerpt: 'I call this system "Semantic Versioning." Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.' -- View this message in context: http://forum.world.st/Semantic-Versioning-tp4630055.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Thanks for the pointer :) I'm wondering though how that can work in a multi dialects ecosystem. At the moment, a given version can have different dependency depending on your smalltalk dialect/version. Isn't that another dimension of the problem? On 13/05/12 19:45, Sean P. DeNigris wrote:
Do you guys know about this? This seems like it could fit really well with Metacello...
Excerpt: 'I call this system "Semantic Versioning." Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.'
-- View this message in context: http://forum.world.st/Semantic-Versioning-tp4630055.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- http://tulipemoutarde.be CA: +1 778 558 3225 BE: +32 65 709 131
fstephany wrote
I'm wondering though how that can work in a multi dialects ecosystem
Hmm... good point. I'm thinking this is handled by Metacello already. IOW, my project's Metacello version 1.3 means "these are the packages you load for 1.3 in all supported platforms, e.g. Pharo 1.3, Squeak 4.3". So if I fix a bug, and now Pharo 1.3 will have to load package.pharo13.3 and Squeak package.squeak43.5, I would declare 1.3.1 in my config with the new packages. Does that sound right? -- View this message in context: http://forum.world.st/Semantic-Versioning-tp4630055p4630150.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
So if I fix a bug, and now Pharo 1.3 will have to load package.pharo13.3 and Squeak package.squeak43.5, I would declare 1.3.1 in my config with the new packages. Does that sound right?
Yep, sounds right. What if you only need the bug fix in the Pharo version and not the Squeak one? The package becomes 1.3.1 in Squeak but is identical to 1.3.0. No big deal I guess... My main concern at the moment is that a MetacelloConfig is always modifiable. It is tempting to fix a version that is already distributed and thus confuse everyone. A release should maybe be a complete new entity (and not editable) hosted somewhere else than in the code repository. The Fuel gsoc would probably help a lot for that. We can maybe imagine something à la Ruby gems?
fstephany wrote
What if you only need the bug fix in the Pharo version and not the Squeak one? The package becomes 1.3.1 in Squeak but is identical to 1.3.0. No big deal I guess...
Well, we're versioning the *project* i.e. the config, not the package, so I don't think there's a conflict. fstephany wrote
My main concern at the moment is that a MetacelloConfig is always modifiable. It is tempting to fix a version that is already distributed and thus confuse everyone.
Yes, this would be a big problem and violates the spirit of Metacello. Just as bad is the fact that Metacello configs are copied all over the place. Is the ConfigurationOf that I download from SqS/projectName the same one as SqS/MetacelloRepository the same as SqS/WhateverForPharo1.4... IMO it's absolutely essential to have one master, and read-only copies everywhere elsewhere. fstephany wrote
We can maybe imagine something à la Ruby gems?
That would be awesome!!! Metacello is sooo young and we've already had so much progress. I'm sure that won't be far off... -- View this message in context: http://forum.world.st/Semantic-Versioning-tp4630055p4630164.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Francois, Regarding the mutability of Metacello configurations ... you are right that it is tempting, but one should never modify a version that has been marked as #released ... it is a convention. One of the appeals of git/github is that a git commit is immutable so all of the artifacts in a commit are guaranteed. Even with git, tags (the only real place to use a version string) are not immutable ... by convention you don't change tags. In the end there is no replacement for discipline... Dale ----- Original Message ----- | From: "Francois Stephany" <tulipe.moutarde@gmail.com> | To: pharo-project@lists.gforge.inria.fr | Sent: Monday, May 14, 2012 9:02:25 AM | Subject: Re: [Pharo-project] Semantic Versioning | | | > So if I fix | > a bug, and now Pharo 1.3 will have to load package.pharo13.3 and | > Squeak | > package.squeak43.5, I would declare 1.3.1 in my config with the new | > packages. Does that sound right? | | Yep, sounds right. | What if you only need the bug fix in the Pharo version and not the | Squeak one? The package becomes 1.3.1 in Squeak but is identical to | 1.3.0. No big deal I guess... | | My main concern at the moment is that a MetacelloConfig is always | modifiable. It is tempting to fix a version that is already | distributed | and thus confuse everyone. | | A release should maybe be a complete new entity (and not editable) | hosted somewhere else than in the code repository. The Fuel gsoc | would | probably help a lot for that. We can maybe imagine something à la | Ruby gems? | |
In the end there is no replacement for discipline...
;) I'm wondering when Fuel and its package loader will be ready, can we imagine a read-only repo of packages? I'm still wrapping my head around packaging and thinking aloud right now. Is there a place where I can read more about how metacello works under the hood? (or is the code easy to read for a total newbie?)
Francois, No documentation for how Metacello works under the covers, but I would be willing to help with your exploration --- your questions and my answers might become the documentation ... There are several layers: - metacello configuration specification language - metacello constructors that transform specification language into specifications - metacello specification classes - project/package/group/repository specifications - repository list specifications - package list specifications - metacello loaders - metacello load directives - metacello toolbox If you are curious about a specific area let me know and I can give you some pointers to where to start exploring code (the debugger/inspector would be your firend) ... Dale ----- Original Message ----- | From: "Francois Stephany" <tulipe.moutarde@gmail.com> | To: pharo-project@lists.gforge.inria.fr | Sent: Monday, May 14, 2012 1:43:12 PM | Subject: Re: [Pharo-project] Semantic Versioning | | | > In the end there is no replacement for discipline... | | ;) | | I'm wondering when Fuel and its package loader will be ready, can we | imagine a read-only repo of packages? I'm still wrapping my head | around | packaging and thinking aloud right now. | | Is there a place where I can read more about how metacello works | under | the hood? (or is the code easy to read for a total newbie?) | |
Regarding Fuel package loader ... Metacello was intended to extensible from the very beginning, so it should be possible to incorporate Fuel and it's package loader into the mix ... the complexity of the project will really depend upon how versions of the packages are managed ... Dale ----- Original Message ----- | From: "Francois Stephany" <tulipe.moutarde@gmail.com> | To: pharo-project@lists.gforge.inria.fr | Sent: Monday, May 14, 2012 1:43:12 PM | Subject: Re: [Pharo-project] Semantic Versioning | | | > In the end there is no replacement for discipline... | | ;) | | I'm wondering when Fuel and its package loader will be ready, can we | imagine a read-only repo of packages? I'm still wrapping my head | around | packaging and thinking aloud right now. | | Is there a place where I can read more about how metacello works | under | the hood? (or is the code easy to read for a total newbie?) | |
I think you are referring to the the fact that there are ways to go through commits and remove sensitive data from them, however, unless I'm mistaken, the SHA of the commit gets changed when you modify it, so you may have "modified a commit" but you have done so by copying it to a new identity. The original commit with the origin SHA still exists and is accessible unless you take further steps to delete the specific commit, so in the end the commit _is_ immutable. Dale ----- Original Message ----- | From: "Douglas Brebner" <squeaklists@fang.demon.co.uk> | To: pharo-project@lists.gforge.inria.fr | Sent: Monday, May 14, 2012 3:07:00 PM | Subject: Re: [Pharo-project] Semantic Versioning | | On 14/05/2012 17:51, Dale Henrichs wrote: | | One of the appeals of git/github is that a git commit is immutable so | all of the artifacts in a commit are guaranteed. | Are you sure? It was my understanding that you can alter a git | commit. Not advisable, but possible. |
Indeed, that's the case. You can rewrite _history_ in git, squashing commits, rebasing chains of commits, etc., but a single commit is effectively immutable because its identity is defined by the SHA-1 hash [1] of its contents: "altering" a commit means creating a new commit with a new identity. [1] Meaning of course that you CAN alter a commit without changing its identity: "simply" find a SHA-1 collision! frank On 15 May 2012 00:14, Dale Henrichs <dhenrich@vmware.com> wrote:
I think you are referring to the the fact that there are ways to go through commits and remove sensitive data from them, however, unless I'm mistaken, the SHA of the commit gets changed when you modify it, so you may have "modified a commit" but you have done so by copying it to  a new identity. The original commit with the origin SHA still exists and is accessible unless you take further steps to delete the specific commit, so in the end the commit _is_ immutable.
Dale
----- Original Message ----- | From: "Douglas Brebner" <squeaklists@fang.demon.co.uk> | To: pharo-project@lists.gforge.inria.fr | Sent: Monday, May 14, 2012 3:07:00 PM | Subject: Re: [Pharo-project] Semantic Versioning | | On 14/05/2012 17:51, Dale Henrichs wrote: | | One of the appeals of git/github is that a git commit is immutable so | all of the artifacts in a commit are guaranteed. | Are you sure? It was my understanding that you can alter a git | commit. Not advisable, but possible. |
----- Original Message ----- | From: "Francois Stephany" <tulipe.moutarde@gmail.com> | To: pharo-project@lists.gforge.inria.fr | Sent: Monday, May 14, 2012 9:02:25 AM | Subject: Re: [Pharo-project] Semantic Versioning | | A release should maybe be a complete new entity (and not editable) | hosted somewhere else than in the code repository. The Fuel gsoc | would | probably help a lot for that. We can maybe imagine something à la | Ruby gems? | With the git/github work, I might be getting close to what you are looking for: ...when you reference a project hosted on github, Metacello downloads the .zip of the project directory and the FileTree repository is marked as readonly... This is awfully close to ruby gems, I think the only thing missing is that whole project directory structure is downloaded instead of just the deployment artifacts... Dale
On 05/14/2012 04:45 AM, Sean P. DeNigris wrote:
Do you guys know about this?
Yes, Eclipse uses it, successfully, for a decade.
This seems like it could fit really well with Metacello...
I don't think you'd be happy with the consequences. First you'd have to define what is API which is hard because everything is public in Smalltalk. And then you have to live by it which means you have much less freedom how you version things. Cheers Philippe
Philippe Marschall-2 wrote
I don't think you'd be happy with the consequences. First you'd have to define what is API which is hard because everything is public in Smalltalk
Right, first you'd have to specify public packages/categories or individual classes (which would be helpful with of without semantic versioning. I sometimes find it difficult to know what classes I'm supposed to use in a library when private helper classes pollute the package/category). Then, any method there that's not in 'private' would be API. Philippe Marschall-2 wrote
And then you have to live by it which means you have much less freedom how you version things.
You'd have less freedom to choose the exact numbering, but that's the whole point! To agree on and stick to a system, losing a little control, but gaining clarity and usability (b.t.w. then Metacello could say "load this dependency version 2.x.x" and know that it'd get all the bug fixes but wouldn't break anything). -- View this message in context: http://forum.world.st/Semantic-Versioning-tp4630055p4630152.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
----- Original Message ----- | From: "Sean P. DeNigris" <sean@clipperadams.com> | To: pharo-project@lists.gforge.inria.fr | Sent: Monday, May 14, 2012 8:11:19 AM | Subject: Re: [Pharo-project] Semantic Versioning | | | Right, first you'd have to specify public packages/categories or | individual | classes (which would be helpful with of without semantic versioning. | I | sometimes find it difficult to know what classes I'm supposed to use | in a | library when private helper classes pollute the package/category). | Then, any | method there that's not in 'private' would be API. Sean, I've always been intrigued by Interfaces in Java...not the interlocking-typing system, but the fact that the public api is explicitly called out. I would think that we could start creating a InterfaceOfXXX class that specifies the public classes and API ... perhaps the class comment would be the primary project documentation... It's a convention, but could be very useful: you can use specifications for validation of test coverage and dependency calculations... Dale
On 05/14/2012 05:11 PM, Sean P. DeNigris wrote:
Philippe Marschall-2 wrote
I don't think you'd be happy with the consequences. First you'd have to define what is API which is hard because everything is public in Smalltalk
Right, first you'd have to specify public packages/categories or individual classes (which would be helpful with of without semantic versioning. I sometimes find it difficult to know what classes I'm supposed to use in a library when private helper classes pollute the package/category). Then, any method there that's not in 'private' would be API.
Philippe Marschall-2 wrote
And then you have to live by it which means you have much less freedom how you version things.
You'd have less freedom to choose the exact numbering, but that's the whole point! To agree on and stick to a system, losing a little control, but gaining clarity and usability (b.t.w. then Metacello could say "load this dependency version 2.x.x" and know that it'd get all the bug fixes but wouldn't break anything).
Theoretically, but some of your other packages may have their own version constraints on this library. This is why installing an Eclipse plugin is np-complete (I shit you not) and a linear equitation solver [1] is used. In addition instead of of simply being an "interface consumer" (using a protocol of an object) you may be a "provider" (sublcass some abstract class). So let's say that from version 2.1.0 to 2.2.0 the library added a new abstract method that you have to implement (my understanding of SemVer is that this fine) now the code breaks because your implementation class just became abstract. Or they change their dependencies which now conflict with the dependencies of some of the dependencies of your other packages. Don't get me wrong you can make it work. But it requires commitment from everybody and most importantly good and correct metadata for everything in the image. This may sound easy but isn't. It's not just plugging something in and suddenly there are only rainbows from there on. [1] http://www.sat4j.org/ Cheers Philippe
participants (6)
-
Dale Henrichs -
Douglas Brebner -
Francois Stephany -
Frank Shearar -
Philippe Marschall -
Sean P. DeNigris