On Hoodie Versioning

[janl]

This is to define how we specify the versioning of Hoodie the project. Hoodie consists of many independent projects each with their own repository, version numbers and release schedule. In order to have a better communicable roadmap, we should have overarching version numbers for the entire project.

The idea now is to have Hoodie version numbers that incorporate all sub-projects on a specific version number. For example, Hoodie 3.5.0 would depend on hoodie-server 4.15.2 and hoodie-plugin-users 2.6.5 and Hoodie 4.0.0 would depend on hoodie-server 5.1.2 and hoodie-plugin-users 3.3.1 (omitting other dependencies for brevity).

To make things transparent across all repositories, we tag all individual issues with a label that expresses which Hoodie release it belongs to. The labels are of the form release-x.y.z. That way, we can use Ubersicht to see which issues belong to which release.

The de-facto enforcement of mapping sub-projects to hoodie versions would happen via hoodie-cli which can specify which version of my-first-hoodie a project will be based on which in turn specifies in its package.json file which versions of hoodie-server and so on are part of an installation.

A word on semantic versioning: we will be following the guide at http://semver-ftw.org — Most importantly, we don’t use version numbers for marketing (except for Hoodie 1.0.0 :) or specifying the stability of Hoodie or a sub-project and we will be following http://nodejs.org/api/documentation.html#documentation_stability_index there (again, except for 1.0.0 which will be our first and only “first, complete stable” release). Every version from then on follows semver-ftw strictly.

Anyhoo.

drops mic

[janl]

Need feedback / thumbs up from @zoepage @caolan @svnlto @gr2m @espy at least. Others please chime in.

[caolan]

+1

[svnlto]

semver-ftw still features ~ when what we really want is ^ see http://www.jakobm.com/semver-in-nodejs-and-npm

other than that, +1

[gr2m]

+1

[janl]

@svnlto yeah, ignore that bit :)

[zoepage]

+1

[espy]

👍 Looks good to me

[janl]

Excellent, thanks everyone!

@zoepage @espy where should we document this?

[zoepage]

I think, it would be good to have the current version numbers with dependencies in the docs / API.
Also having a blogpost when releasing a new stable version, where we can describe the changes would be awesome, too.

[janl]

Ab yes excellent. We should defines the release process as well. I'll take a stab later.

On 05.02.2014, at 17:29, Ola Gasidlo [email protected] wrote:

I think, it would be good to have the current version numbers with dependencies in the docs / API.
Also having a blogpost when releasing a new stable version, where we can describe the changes would be awesome, too.

—
Reply to this email directly or view it on GitHub.