[iTowns-dev] Release: name and version?
Alexandre Devaux
Alexandre.Devaux at ign.fr
Thu Jun 29 06:13:21 PDT 2017
Hi,
I would go for 1) too. "rename itowns repo into itowns-old (for instance), and we rename itowns2 into itowns"
--
Alexandre Devaux
Chargé d'Etudes et de Recherche
Laboratoire MATIS, IGN
Tel: 01 43 98 85 73
________________________________________
De : iTowns-dev [itowns-dev-bounces at lists.osgeo.org] de la part de itowns-dev-request at lists.osgeo.org [itowns-dev-request at lists.osgeo.org]
Date d'envoi : jeudi 29 juin 2017 13:51
À : itowns-dev at lists.osgeo.org
Objet : iTowns-dev Digest, Vol 13, Issue 5
Send iTowns-dev mailing list submissions to
itowns-dev at lists.osgeo.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osgeo.org/mailman/listinfo/itowns-dev
or, via email, send a message with subject or body 'help' to
itowns-dev-request at lists.osgeo.org
You can reach the person managing the list at
itowns-dev-owner at lists.osgeo.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of iTowns-dev digest..."
Today's Topics:
1. Re: Video in repo (Augustin Trancart)
2. Re: Video in repo (Thomas Broyer)
3. Re: Release: name and version? (Vincent Picavet (ml))
4. Re: Video in repo (Vincent Picavet (ml))
5. Re: Video in repo (Augustin Trancart)
----------------------------------------------------------------------
Message: 1
Date: Thu, 29 Jun 2017 12:13:06 +0200
From: Augustin Trancart <augustin.trancart at oslandia.com>
To: Thomas Broyer <t.broyer at atolcd.com>
Cc: "itowns-dev at lists.osgeo.org" <itowns-dev at lists.osgeo.org>
Subject: Re: [iTowns-dev] Video in repo
Message-ID: <619a829d-7f33-cf9c-58cb-1f4b9ff34c45 at oslandia.com>
Content-Type: text/plain; charset="utf-8"
Yes, agree with the idea of removing other big obsolete files as well.
I'm not too worried about pull/pushes. If we require the files to be removed
before merge, these commits would become unreachable after the force-push, and
would eventually be garbage collected (providing we are careful at removing old
branches).
Augustin Trancart - Oslandia
augustin.trancart at oslandia.com
On 29/06/2017 12:03, Thomas Broyer wrote:
> 15 months ago (or so), big files were added to the project and then removed, and
> I also floated the idea of a history rewrite. I never got the "go" so it hasn't
> been done. Iff we go that road for the video file, I suggest we also get rid of
> those old commits.
>
> I don't have a strong opinion whether this should be done, but it's clear that
> it's now or never.
>
> I'd suggest we eventually find a way to somehow reject pull requests (we
> apparently can't reject commits/pushes) with big files (or many smaller files!);
> possibly an additional check in Travis, I don't know.
>
> 2017-06-29 11:32 GMT+02:00 Augustin Trancart <augustin.trancart at oslandia.com
> <mailto:augustin.trancart at oslandia.com>>:
>
> Hi there!
>
> Quick question with the release in sight: a video of 24M has been added (in
> aabc913) and removed later (in b321c01) in the repository. This makes the clone
> of the repository quite long even though the video is not in master any more.
> Should we rewrite the history to get rid of it?
>
> It's possible, but it implies a force-push on master. It means that everybody
> will need to use "git rebase --onto master <commit-range>" for all their
> branches after this push is done and force-push them (and maybe a git reset
> --hard on their local master, I'm not sure how clever git is nowadays).
>
> It's a low risk process (we'll keep a copy of the old master around), but it's a
> bit of a hassle and requires synchronization between us. I believe it is
> possible, but if we want to do it, we'd better do it now, before success hits us
> hard and we have thousands of contributors (yeah, I'm an optimistic kind of guy
> ;-) )
>
> Thoughts?
>
> --
> Augustin Trancart - Oslandia
> augustin.trancart at oslandia.com <mailto:augustin.trancart at oslandia.com>
>
>
> _______________________________________________
> 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
>
-------------- 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/674fd290/attachment-0001.sig>
------------------------------
Message: 2
Date: Thu, 29 Jun 2017 12:34:13 +0200
From: Thomas Broyer <t.broyer at atolcd.com>
To: augustin.trancart at oslandia.com
Cc: "itowns-dev at lists.osgeo.org" <itowns-dev at lists.osgeo.org>
Subject: Re: [iTowns-dev] Video in repo
Message-ID:
<CA+9O_-QNmXJX2rs9SFr-h+KrVN7ZRSbSAYoqLq5CLZfbOvy87g at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
2017-06-29 12:13 GMT+02:00 Augustin Trancart <augustin.trancart at oslandia.com
>:
> Yes, agree with the idea of removing other big obsolete files as well.
>
> I'm not too worried about pull/pushes. If we require the files to be
> removed
> before merge, these commits would become unreachable after the force-push,
> and
> would eventually be garbage collected (providing we are careful at
> removing old
> branches).
Not sure I understand that last paragraph.
My remark wrt rejecting pull requests (or pushes) with big files was to
prevent this situation from happening again (in other words, as you said,
"require the files to be removed before merge", but automate it).
Note also that GitHub will keep the files anyway in their special
refs/pull/ references [1], you'll just never sync them (unless you want it)
because (by default) Git only syncs refs/heads/ and refs/tags/
[1] https://help.github.com/articles/checking-out-pull-requests-locally/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/itowns-dev/attachments/20170629/74f11c2d/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 29 Jun 2017 12:58:19 +0200
From: "Vincent Picavet (ml)" <vincent.ml at oslandia.com>
To: Thomas Broyer <t.broyer at atolcd.com>,
augustin.trancart at oslandia.com
Cc: "itowns-dev at lists.osgeo.org" <itowns-dev at lists.osgeo.org>
Subject: Re: [iTowns-dev] Release: name and version?
Message-ID: <5e667061-9c34-12cd-662f-f0ccb151d0ac at oslandia.com>
Content-Type: text/plain; charset=utf-8
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
>
------------------------------
Message: 4
Date: Thu, 29 Jun 2017 13:00:55 +0200
From: "Vincent Picavet (ml)" <vincent.ml at oslandia.com>
To: Pierre-Eric Pelloux-Prayer
<pierre-eric.pelloux-prayer at oslandia.com>, itowns-dev at lists.osgeo.org
Subject: Re: [iTowns-dev] Video in repo
Message-ID: <2cef31e3-b12c-cef0-3592-eea29b19c76d at oslandia.com>
Content-Type: text/plain; charset=utf-8
Hello,
+1 also on history rewrite.
Try to gather all big files, not just the video.
Doing this just before the release would probably minimize the number of
branches concerned by this change ( aka : "merge now or expect trouble"
;-) .
Vincent
On 29/06/2017 11:53, Pierre-Eric Pelloux-Prayer wrote:
> +1 let's do this before the first release.
>
>
> Le 29/06/2017 à 11:32, Augustin Trancart a écrit :
>> Hi there!
>>
>> Quick question with the release in sight: a video of 24M has been added (in
>> aabc913) and removed later (in b321c01) in the repository. This makes the clone
>> of the repository quite long even though the video is not in master any more.
>> Should we rewrite the history to get rid of it?
>>
>> It's possible, but it implies a force-push on master. It means that everybody
>> will need to use "git rebase --onto master <commit-range>" for all their
>> branches after this push is done and force-push them (and maybe a git reset
>> --hard on their local master, I'm not sure how clever git is nowadays).
>>
>> It's a low risk process (we'll keep a copy of the old master around), but it's a
>> bit of a hassle and requires synchronization between us. I believe it is
>> possible, but if we want to do it, we'd better do it now, before success hits us
>> hard and we have thousands of contributors (yeah, I'm an optimistic kind of guy
>> ;-) )
>>
>> Thoughts?
>>
>>
>>
>> _______________________________________________
>> iTowns-dev mailing list
>> iTowns-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/itowns-dev
>>
> _______________________________________________
> iTowns-dev mailing list
> iTowns-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/itowns-dev
>
------------------------------
Message: 5
Date: Thu, 29 Jun 2017 13:51:40 +0200
From: Augustin Trancart <augustin.trancart at oslandia.com>
To: Thomas Broyer <t.broyer at atolcd.com>
Cc: "itowns-dev at lists.osgeo.org" <itowns-dev at lists.osgeo.org>
Subject: Re: [iTowns-dev] Video in repo
Message-ID: <dc82d15c-3207-1390-3971-d16edfd62d7e at oslandia.com>
Content-Type: text/plain; charset="utf-8"
I basically trust maintainer not to merge big files, but yes, if we can automate
it, it's even better.
Augustin Trancart - Oslandia
augustin.trancart at oslandia.com
On 29/06/2017 12:34, Thomas Broyer wrote:
>
>
> 2017-06-29 12:13 GMT+02:00 Augustin Trancart <augustin.trancart at oslandia.com
> <mailto:augustin.trancart at oslandia.com>>:
>
> Yes, agree with the idea of removing other big obsolete files as well.
>
> I'm not too worried about pull/pushes. If we require the files to be removed
> before merge, these commits would become unreachable after the force-push, and
> would eventually be garbage collected (providing we are careful at removing old
> branches).
>
>
> Not sure I understand that last paragraph.
> My remark wrt rejecting pull requests (or pushes) with big files was to prevent
> this situation from happening again (in other words, as you said, "require the
> files to be removed before merge", but automate it).
>
> Note also that GitHub will keep the files anyway in their special refs/pull/
> references [1], you'll just never sync them (unless you want it) because (by
> default) Git only syncs refs/heads/ and refs/tags/
> [1] https://help.github.com/articles/checking-out-pull-requests-locally/
-------------- 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/02a1cc9b/attachment.sig>
------------------------------
Subject: Digest Footer
_______________________________________________
iTowns-dev mailing list
iTowns-dev at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/itowns-dev
------------------------------
End of iTowns-dev Digest, Vol 13, Issue 5
*****************************************
More information about the iTowns-dev
mailing list