> Can you really promise that no one 1.X.Y libuv version will change > anything at API level in a non backwards-compatible manner? really?
I don't really see why this would be an issue; we can always add functions if we need to expose additional capabilities. On Monday, September 1, 2014 7:01:56 PM UTC+2, Iñaki Baz Castillo wrote: > > 2014-08-29 20:00 GMT+02:00 Saúl Ibarra Corretgé <[email protected]>: > > We believe the current design is mature enough to call it 1.0.0 and > > support it for an extended period of time. APIs will be allowed to > > evolve as per SemVer (semver.org) and ABI will remain stable throughout > > the 1.x series of libuv. > > > > So, what's next then? libuv 1.x will continue to evolve as per the > > current design, but we'll start working on what will eventually become > > libuv 2.0.0 > > > It is great that you jump to 1.0.0 (libuv deserves it), but I don't like > SemVer: > > > -------------------------------------------------- > Given a version number MAJOR.MINOR.PATCH, increment the: > > MAJOR version when you make incompatible API changes, > MINOR version when you add functionality in a backwards-compatible manner, > and > PATCH version when you make backwards-compatible bug fixes. > --------------------------------------------------- > > > Can you really promise that no one 1.X.Y libuv version will change > anything at API level in a non backwards-compatible manner? really? > > > I prefer that just two versions with same MAJOR and MINOR numbers are > API compatible. > > -- > Iñaki Baz Castillo > <[email protected]> > -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
