[iTowns-dev] itowns V1 : RC1 ?

[Mathieu Brédif]

Since we got no bad testing feedback, thus I agree with Vincent to
release now (but I am not part of the PSC :) ).

--
Mathieu Brédif
IGN - Institut National de l'Information Géographique et Forestière
Laboratoire MATIS
73 avenue de Paris 94165 Saint-Mandé
recherche.ign.fr/labos/matis/~bredif
Tel: +33 (0)1 43 98 83 19


On Tue, Feb 16, 2016 at 1:47 PM, Vincent Picavet (ml)
<vincent.ml at oslandia.com> wrote:
> Hello
>
>
> On 16/02/2016 11:52, Thomas Broyer wrote:
>> 2016-02-16 11:32 GMT+01:00 Mathieu Brédif <mathieu.bredif at ign.fr
>> <mailto:mathieu.bredif at ign.fr>>:
>>     There are still a sizeable amount of dead code and hardcoded values,
>>     some 404 errors, and room for improvement, but I propose to consider
>>     the master branch of itowns V1, so that we consider it as a technology
>>     preview and focus our efforts on the V2.
>>     Could you please all test it and report any blocker ?
>>     http://itowns.github.io/v1demo.html
>>     http://itowns.github.io/itowns-sample-data-small/
>>     http://itowns.github.io/itowns-sample-data/
>
> Looks good to me (even on 4K screen).
> I am in favor of publishing directly this release as Version 1.0, and
> improve and fix things in dot-releases shortly afterwards.
>
>> Side note: not quite a fan of the toggles between panoramic images and
>> 3D buildings; should probably be a single toggle rather than 2 linked ones.
>> Also, enabling laser cloud when in 3D buildings view has some unexpected
>> behavior (seems to load based on "what would be seen had the camera been
>> at ground level", and when zooming in to another place –clicking on a
>> street or building– the already-loaded or still-loading cloud can be
>> seen "through" the buildings)
>
> Indeed, could be better, but no blocker for v1.0. Feel free to open new
> issues :-)
>
>>     I am now going to close open issues and eventually open new ones.
>>     What is the release process ?
>>
>>
>> First thing would be to create a tag (prefer annotated tags; i.e. 'git
>> tag -a -m "Releasing v1.0" v1.0'; I tend to name version tags with a "v"
>> prefix too).
>
> Same here. And globally use semver.org for versioning.
> Not that a RELEASE.md document would be helpful, at least for itowns 2.
>
>> I wonder if we should "deploy" a compiled itowns.js at, e.g.
>> itowns.github.io/itowns/1.0/itowns.js
>> <http://itowns.github.io/itowns/1.0/itowns.js>, in addition to
>> dist/itowns.js (which could still be updated regularly to reflect
>> ongoing developments, even though our focus shifts to the V2).
>> We could also (or instead), attach the compiled script to the GitHub
>> release page.
>
> We can do that for next releases, not a blocker IMHO.
>
>> Also: do we want to include a version number in the compiled JS? do we
>> want to include a "banner comment" with, e.g., licensing information?
>> That would need to be done before we tag the release.
>
> We should do that at least for 2.0, and can backport to 1.1 or later
> version. Not a blocker for 1.0 for me, as the licence is clearly stated
> in the LICENSE.md file ( note that for next release we should also state
> MIT option).
>
> I'd say go release !
>
> Who tags it ? If nobody goes for it, I do it today at 16:00.
> As soon as it is done, we can update the website and communicate. I have
> mostly written the release text already, can finish it today.
>
> Vincent
>
>> Cordialement,
>> --
>> Thomas Broyer
>> Atol Conseils et Développements
>>
>>
>>
>> _______________________________________________
>> iTowns-dev mailing list
>> iTowns-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/itowns-dev
>>
>