[iTowns-dev] Release: name and version?

[Vincent Picavet (ml)]

Hi,

On 29/06/2017 12:14, Thomas Broyer wrote:
> 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…

Agree with this. Renaming itowns to itowns1 or itowns-legacy seems best
to avoid confusion, and keep itowns name for current version.

As for the name change, it could be an option, but a lot of
communication has been made around itowns already, especially at IGN, so
I think it would be difficult.

Vincent


> 
> 2017-06-29 11:42 GMT+02:00 Augustin Trancart
> <augustin.trancart at oslandia.com <mailto: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
>     <https://www.npmjs.com/package/itowns>
>     [2] http://semver.org/
>     --
>     Augustin Trancart - Oslandia
>     augustin.trancart at oslandia.com <mailto: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 <mailto:iTowns-dev at lists.osgeo.org>
>     https://lists.osgeo.org/mailman/listinfo/itowns-dev
>     <https://lists.osgeo.org/mailman/listinfo/itowns-dev>
> 
> 
> 
> 
> -- 
> 
> Cordialement,
> -- 
> Thomas Broyer
> Atol Conseils et Développements
> 
> 
> 
> _______________________________________________
> iTowns-dev mailing list
> iTowns-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/itowns-dev
>