<div dir="ltr">FWIW, my vote would go to 1/ (particularly if we *also* rewrite the Git history)<div>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).</div><div><br></div><div>Either that or finding a new name…</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-06-29 11:42 GMT+02:00 Augustin Trancart <span dir="ltr"><<a href="mailto:augustin.trancart@oslandia.com" target="_blank">augustin.trancart@oslandia.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi there!<br>
<br>
Our first release approaching, I have some questions about it about the package<br>
name and its version.<br>
<br>
The current situation: our repo is currently called itowns2. We have the old<br>
repo called itowns. The npm package (a 0.0.0-alpha published for testing<br>
purpose) is currently called itowns[1]. I see several possibilities:<br>
<br>
1/ we stick with the "itowns" name. We rename itowns repo into itowns-old (for<br>
instance), and we rename itowns2 into itowns. We release v2.0.0 on 5th of July<br>
(imho we can't release another number to avoid confusion with itowns1)<br>
<br>
2/ we stick with the current situation: "itowns" for the npm package only, and<br>
"itowns2" for the repo. After all, the repo is linked in the npm package page.<br>
We release a v2.0.0 for the same reason as 1/<br>
<br>
3/ We keep the name itowns2 for this release everywhere. Therefore, we keep the<br>
github repo as it is and we create a new npm package named itowns2 (and delete<br>
package itowns, because it is really itowns2 inside). We can release whatever<br>
version number we want.<br>
<br>
4/ another combination of the above/solution?<br>
<br>
<br>
I don't really like current situation (aka 2/), because I think it's the most<br>
confusing setup (different name for the package and the repo, and an old itowns<br>
repo with same name as package name still in existence).<br>
<br>
1/ has the advantage of reducing the confusion between itowns and itowns2<br>
(because there would be only itowns) and be clear about which one is the current<br>
one, but it forces us to rename some repos (never ideal) and release a v2<br>
(instead of a v0 or v1 for instance).<br>
<br>
3/ has the advantage of being the least disruptive and the more respectful of<br>
the history of the project. If we choose this solution, we must be clear in<br>
itowns old repo that new development should be done in itowns2 repo. If we<br>
choose this, I would advocate to release a v0.something, because in semver[2],<br>
0.x.x versions do not need to have a stable API. Then we can release a v1 some<br>
weeks/months before the geoportail itowns release. It's my preferred choice.<br>
<br>
<br>
For a more general thought about version numbers, I would like to follow<br>
semantic versioning[2]. I think it's a great way to convey incompatible change<br>
informations to our users. For this a prerequisite would be to define our Public<br>
API. I propose a simple criterion : everything that's currently documented in<br>
our jsdoc page is our current API. Everything else is not, and we make it clear so.<br>
<br>
What do you think about all that?<br>
<br>
[1] <a href="https://www.npmjs.com/package/itowns" rel="noreferrer" target="_blank">https://www.npmjs.com/package/<wbr>itowns</a><br>
[2] <a href="http://semver.org/" rel="noreferrer" target="_blank">http://semver.org/</a><br>
<span class="HOEnZb"><font color="#888888">--<br>
Augustin Trancart - Oslandia<br>
<a href="mailto:augustin.trancart@oslandia.com">augustin.trancart@oslandia.com</a><br>
</font></span><br>
PS: We can examine crazier ideas too, like another name entirely? eg Barium<br>
(Cesium is elem n°55, Barium is 56, so Cesium++ ;-) )?<br>
<br>
<br>______________________________<wbr>_________________<br>
iTowns-dev mailing list<br>
<a href="mailto:iTowns-dev@lists.osgeo.org">iTowns-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/itowns-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/itowns-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="font-size:12.8px"><br>Cordialement,</div><div style="font-size:12.8px">-- </div><div style="font-size:12.8px">Thomas Broyer</div><div style="font-size:12.8px">Atol Conseils et Développements</div><div><br></div></div></div>
</div>