[iTowns-dev] Release: name and version?

[Augustin Trancart]

Hi there!

Our first release approaching, I have some questions about it about the package
name and its version.

The current situation: our repo is currently called itowns2. We have the old
repo called itowns. The npm package (a 0.0.0-alpha published for testing
purpose) is currently called itowns[1]. I see several possibilities:

1/ we stick with the "itowns" name. We rename itowns repo into itowns-old (for
instance), and we rename itowns2 into itowns. We release v2.0.0 on 5th of July
(imho we can't release another number to avoid confusion with itowns1)

2/ we stick with the current situation: "itowns" for the npm package only, and
"itowns2" for the repo. After all, the repo is linked in the npm package page.
We release a v2.0.0 for the same reason as 1/

3/ We keep the name itowns2 for this release everywhere. Therefore, we keep the
github repo as it is and we create a new npm package named itowns2 (and delete
package itowns, because it is really itowns2 inside). We can release whatever
version number we want.

4/ another combination of the above/solution?


I don't really like current situation (aka 2/), because I think it's the most
confusing setup (different name for the package and the repo, and an old itowns
repo with same name as package name still in existence).

1/ has the advantage of reducing the confusion between itowns and itowns2
(because there would be only itowns) and be clear about which one is the current
one, but it forces us to rename some repos (never ideal) and release a v2
(instead of a v0 or v1 for instance).

3/ has the advantage of being the least disruptive and the more respectful of
the history of the project. If we choose this solution, we must be clear in
itowns old repo that new development should be done in itowns2 repo. If we
choose this, I would advocate to release a v0.something, because in semver[2],
0.x.x versions do not need to have a stable API. Then we can release a v1 some
weeks/months before the geoportail itowns release. It's my preferred choice.


For a more general thought about version numbers, I would like to follow
semantic versioning[2]. I think it's a great way to convey incompatible change
informations to our users. For this a prerequisite would be to define our Public
API. I propose a simple criterion : everything that's currently documented in
our jsdoc page is our current API. Everything else is not, and we make it clear so.

What do you think about all that?

[1] https://www.npmjs.com/package/itowns
[2] http://semver.org/
-- 
Augustin Trancart - Oslandia
augustin.trancart at oslandia.com

PS: We can examine crazier ideas too, like another name entirely? eg Barium
(Cesium is elem n°55, Barium is 56, so Cesium++ ;-) )?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/itowns-dev/attachments/20170629/dbdab019/attachment.sig>