As long as we don't commit to a major 1.0.0 release, we aren't promising api stability. npm users using "~0.4.1" will automaticall get an update for a bugfix to 0.4.2, but not to 0.5.0.
A major version creates a commitment to maintain that version in a branch. And since things are still moving quite fast, it might be better to wait. > Am 05.03.2014 um 04:36 schrieb Sean Colyer <[email protected]>: > > I know I haven't been super active lately, but I'm trying to get up to speed > on a lot of the excellent progress we've been making lately. > > One of the things I've noticed is that I think it would be easier to follow > updates to the library and a consumer of the library if we set a little > better guidelines around how we follow semantic versioning within our library. > > I noticed that between v0.3.0 and v0.4.1 for example we changed some of the > arguments to src/openpgp.js and keyring files for example. I believe these > changes could potentially cause some backwards compatibility issues. > > If something breaks possible backwards compatibility even in a seemingly > small way, we should really bump major versions, we shouldn't be afraid to > bump them. > > I'd like to propose that changes to public api (src/openpgp.js, util, and > keyring at least), that modify/remove inputs/outputs we go to a version bump. > > I propose that when merging a commit that has one of these changes, that is > when the major version number is also bumped. A component of this would be to > also rely on prerelease tags until we cut a tags. > > Example: > Let's say we're now > v0.4.1-0 > someone makes a major commit > v1.0.0-0 > we cut a tag > v1.0.0 is cut and 1.0.1-0 is open for business > > Thoughts? > _______________________________________________ > > http://openpgpjs.org > Subscribe/unsubscribe: http://list.openpgpjs.org _______________________________________________ http://openpgpjs.org Subscribe/unsubscribe: http://list.openpgpjs.org
