Samual,

Thanks this is actually helpful. Just to be clear I wasn't suggesting
adding semantics about stability to version numbers. I think those
semantics already exist. People have an expectation that a 1.0 project
has some level of stability. However, I am leaning towards ignoring
that and going with just a consistant versioning model that you
suggest here.

Eric

On Mon, Feb 28, 2011 at 2:10 PM, Samuel <[email protected]> wrote:
> Is there any documentation or comments on the semantics of sinan and
> faxien versioning?
>
> We've been using different versioning policies at work and it seems we
> found one that's been quite stable for a couple of years. Funny
> enough, Tom Preston-Werner has written something that almost serve as
> documentation for what we do, so it seems more people had similar
> ideas out there:
>
> http://semver.org/
>
> Basically, versions are X.Y.Z where Z is the patch level (changes that
> don't change the public API), Y is for backwards compatible changes
> and X for incompatible changes. They suggest using version 0.x.x as
> special line for development versions that need not keep any
> compatibility (we don't do that).
>
> We use versioning as an aid between development and operations, since
> ops guys want to control when an upgrade maybe dangerous. Stability is
> more a testing thing, so all our attempts to reflect that in the
> version number failed since it's quite dynamic. For example, we once
> tried to use a suffix being, to speak, a for betas, b for
> system-tested, c for pre-production tested, etc. It ended up in betas
> installed everywhere because no one found any value on rebranding
> already versioned releases once they promoted after a testing stage.
>
> What you'r suggesting is adding some kind of semantics about stability
> in the version number, I guess. Maybe you could use the first number
> for that and the other three for plain semantic versioning.
>
> Cheers
> --
> Samuel
>
> --
> You received this message because you are subscribed to the Google Groups 
> "erlware-dev" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/erlware-dev?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"erlware-dev" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/erlware-dev?hl=en.

Reply via email to