Hey, I did not suggest using any existing deployment branches for this purpose. If we use the tags for demotime, we can just have a demotime branch. The Indeed. Git tags are not "internal" though. They affect everyone dealing with the repo. Thus if we go do something with them which is unexpected for consumers, we negatively affect them. Look here for instance: https://github.com/wikimedia/mediawiki-extensions-Diff/ GitHub thinks it has 36 releases, and packagist things the latest release is 2013-06-something. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --

Hey, Hard to say what other teams do internally. I've not seen any branches for this, though I have not been looking for them either, and unlike tags these get not thrown into your face, so that does not say anything. All I can say is that for all projects I have seen recently, tags where not used for the purpose we are using them for. That would work, but seems nonsensical to me: tags are immutable, branches And this leads to problems how? Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --

Hey, As long as nobody messes with the branch, it doesn't. Just like using a Do you object against trying this approach and seeing if troubles actually occur? Also keep in mind that tags are not set in stone. You can update them. And unlike with constants in programming languages, that really should not be changed, and to which change would be hard to detect, git has this nice history feature. And who is to say we never want to update the demo thing? We never run into situations where we tag and then figure that one commit we wanted in was not there yet, and thus need to re-tag? Using branches as proposed will fix a concrete problem - as with almost any type of change, there is potential for unintended effects, and there are trade-offs. In a case so trivial as this, we can just switch back if problems occur. In fact, I'm quite certain we already spend more time discussing this now then we would have dealing with an hypothetical unacceptable problem and making the switch back. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --

According to the official git docu "Like most VCSs, Git has the ability to tag specific points in history as being important. Generally, people use this functionality to mark release points (v1.0, and so on)." So, yeah, it would allow for Daniel's interpretation, which I indeed share. But looking at actual usage, my completely unrepresentative survey confirms that they are used for marking releases and releace-candidates mostly. I couldn't find a single instance where they use it for, well, tagging a specific version for anything else. It seems that a number of widespread tools are also assuming this usage. I would have suggested to take this to the weekly meeting to discuss, but since we already spend sufficiently time here on the topic I would suggest to * switch to tags for releases * think about our release strategy * use either a branch for demo or just take the commit-hash OK? Cheers, Denny 2013/7/22 Daniel Kinzler <daniel.kinzler(a)wikimedia.de> -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

Am 22.07.2013 12:28, schrieb Denny Vrandečić: I'd recommend to still have a release branch for major releases, and user tags for the initial .0 release and subsequent bug fix releases, like we do it for mediawiki core. We should also keep using branches for deployment, for easy tracking of backports. We cold in addition tag versions that actually got deployed. I don't see how we could sanely use tags on master for releases, that would make it very hard to do backports/bug fix releases. Ugh :P The commit-hash is going to be a mess, since we are dealing with an increasing number of git repos. We'd need one hash for each. Much better to have an aptly named branch (or tag). -- daniel

Yeah, Daniel, Jeroen, good point. So branches + tags on the branch for releases. Does this mean master doesn't get tagged at all? Re: deleting the existing tags -- please wait with this until Abraham says OK, I am not sure if there are maybe some process that relies on this. He will be back tomorrow. Cheers, Denny 2013/7/22 Jeroen De Dauw <jeroendedauw(a)gmail.com> -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

On Mon, Jul 22, 2013 at 11:32 AM, Daniel Kinzler <daniel.kinzler(a)wikimedia.de> wrote: Tag on main = release his is how I am used to it from other projects too. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Technical Projects Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.