Semantic Versioning

[Tom Robinson]

http://semver.org/

I think it would be good for us to either require or at least
recommend this or something like it for CommonJS packages.

-tom

--
tlrobinson{.net,@gmail.com, on twitter}

[Kris Kowal]

On Tue, Dec 15, 2009 at 6:20 PM, Tom Robinson <tlrob...@gmail.com> wrote:
> http://semver.org/
>
> I think it would be good for us to either require or at least
> recommend this or something like it for CommonJS packages.

Awesome.

Kris Kowal

[Kevin Dangoor]

On Tue, Dec 15, 2009 at 9:20 PM, Tom Robinson <tlrob...@gmail.com> wrote:

http://semver.org/

I think it would be good for us to either require or at least
recommend this or something like it for CommonJS packages.

+1

I think this is good practice in general, but to have it actually spelled out does make you think twice about shipping release X.

That said, I'm not sure what it would mean to "require" this. It's not technically possible to require it. But, I think it's certainly worth saying that it's recommended and failure to follow will lead to much ridicule.

Kevin

--
Kevin Dangoor

work: http://labs.mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com

[Dean Landolt]

On Tue, Dec 15, 2009 at 10:16 PM, Kevin Dangoor <dan...@gmail.com> wrote:

On Tue, Dec 15, 2009 at 9:20 PM, Tom Robinson <tlrob...@gmail.com> wrote:

http://semver.org/

I think it would be good for us to either require or at least
recommend this or something like it for CommonJS packages.

+1

I think this is good practice in general, but to have it actually spelled out does make you think twice about shipping release X.

That said, I'm not sure what it would mean to "require" this. It's not technically possible to require it. But, I think it's certainly worth saying that it's recommended and failure to follow will lead to much ridicule.

Isn't that really the case with all our specs? Implementers can pretty much comply partially or extend any way they want. Of course, we can write test suites to test compliance for our other specs -- that's not really feasible for this kind of spec.

That said, +1 to standardizing. It's great to see this codified in language we can all understand.

[mob]

> I think it would be good for us to either require or at least  
> recommend this or something like it for CommonJS packages.

+9

CommonSense for CommonJS

--mob

[Tiago Rodrigues]

On Wed, Dec 16, 2009 at 3:16 AM, Kevin Dangoor <dan...@gmail.com> wrote:
> On Tue, Dec 15, 2009 at 9:20 PM, Tom Robinson <tlrob...@gmail.com> wrote:
>>
>> http://semver.org/
>>
>> I think it would be good for us to either require or at least
>> recommend this or something like it for CommonJS packages.
>
> +1
>
> I think this is good practice in general, but to have it actually spelled
> out does make you think twice about shipping release X.
>
> That said, I'm not sure what it would mean to "require" this. It's not
> technically possible to require it. But, I think it's certainly worth saying
> that it's recommended and failure to follow will lead to much ridicule.

The problem with "requiring" this is that your infrastructure needs to
be ready for it, and most, at least to me, don't seem to be.

What I mean is: this is doable, as long as you can install multiple
package versions at once, and many package systems aren't ready to
deal with this.

If you can't do this, people will stray from the methodology and it'll
be worthless to follow this. People will start installing things by
hand and...well, dependency hell all over again.


--
Tiago Rodrigues
http://www.trodrigues.net
E-Mail / MSN Messenger / Jabber / GTalk:
tmcrodrigues [at] gmail [dot] com
Skype: trodrigues.net

[Christoph Dorn]

mob wrote:
>> I think it would be good for us to either require or at least
>> recommend this or something like it for CommonJS packages.

+1 for recommending it and building tusk round it

Not sure if we can require any one schema. There are too many entrenched
variations. We could however require that a pure JS parser is provided
for each schema that can generate an object (for each version string)
with a common set of properties on top of which package management
systems are built.

Not all schemata will be able to support all features but at least they
will all support a common subset.

Christoph

[mob]

I added a tentative requirement to the Packages 0.1 proposal for this.

--mob

[Irakli Gozalishvili]

Only think is missing IMO is versions like beta periods between 2.x.x and 3.x.x where code is not backwards compatible but not mature enough.
--
Irakli Gozalishvili
Web: http://rfobic.wordpress.com/
Address: Taksteeg 3 - 4, 1012PB Amsterdam, Netherlands

On Wed, Dec 16, 2009 at 22:28, mob <m...@embedthis.com> wrote:

I added a tentative requirement to the Packages 0.1 proposal for this.

--mob

--

You received this message because you are subscribed to the Google Groups "CommonJS" group.
To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.

[Dean Landolt]

On Wed, Dec 16, 2009 at 5:21 PM, Irakli Gozalishvili <rfo...@gmail.com> wrote:

Only think is missing IMO is versions like beta periods between 2.x.x and 3.x.x where code is not backwards compatible but not mature enough.

Exactly. This just came up in the Packages 0.1 proposal thread. I wonder how this could be reconciled.

[Zachary Carter]

Perhaps it would be useful to apply SV to our spec versions as well. The concepts of major, minor, and patch translate accordingly.

[Kevin Dangoor]

On Thu, Dec 17, 2009 at 11:02 AM, Zachary Carter <zack....@gmail.com> wrote:

Perhaps it would be useful to apply SV to our spec versions as well. The concepts of major, minor, and patch translate accordingly.

Yes, agreed.