[iTowns-dev] Release: name and version?

[Thomas Broyer]

FWIW, my vote would go to 1/ (particularly if we *also* rewrite the Git
history)
Rename itowns/itowns to itowns/itowns1 and itowns/itowns2 to itowns/itowns,
add a note to the README that iTowns 1 can be found at itowns/itowns1, and
release a v2 (if it makes no guarantee about API stability, then label it
as alpha or beta, or release candidate depending on the [lack of]
confidence in API [in]stability).

Either that or finding a new name…

2017-06-29 11:42 GMT+02:00 Augustin Trancart <augustin.trancart at oslandia.com
>:

> 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++ ;-) )?
>
>
> _______________________________________________
> iTowns-dev mailing list
> iTowns-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/itowns-dev
>
>


-- 

Cordialement,
-- 
Thomas Broyer
Atol Conseils et Développements
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/itowns-dev/attachments/20170629/6bb25f63/attachment-0001.html>