<div dir="ltr"><font face="arial, helvetica, sans-serif"><span style="color:rgb(0,0,0);font-size:13px">Richard,</span><br></font><div><span style="color:rgb(0,0,0);font-size:13px"><font face="arial, helvetica, sans-serif"><br>

</font></span></div><div style><span style="color:rgb(0,0,0);font-size:13px"><font face="arial, helvetica, sans-serif">If you are talking about having a different github repo for each release that would be really ugly and I'm not to keen of that idea.  git has the branching and tagging stuff for a reason and there isn't reason that we can't use it here for this. This would also make tracking version changes really hard.</font></span></div>

<div style><span style="color:rgb(0,0,0);font-size:13px"><font face="arial, helvetica, sans-serif"><br></font></span></div><div style><font color="#000000" face="arial, helvetica, sans-serif">My suggestion is to have a branch for each release with a tag at each minor release on that branch, master is always kept up to date with what is in dev, and a branch is made at release time.</font></div>

<div style><font face="arial, helvetica, sans-serif"><br></font></div><div style><font color="#000000" face="arial, helvetica, sans-serif">We can provide shell scripts for people to clone the repo and checkout the most current release to work on.  So in the upcoming 2.0 case we could have a script that clones the repo and sets the branch to master, people can work on that until we release 2.0 at which point someone creates a 2.0 branch a "Switch to 2.0" shell/batch script.</font></div>

<div style><font color="#000000" face="arial, helvetica, sans-serif"><br></font></div><div style><font face="arial, helvetica, sans-serif"><font color="#000000">Deploying to the webserver is easy </font><span style="background-color:rgb(238,238,238);color:rgb(0,0,0);font-size:14px;line-height:18px">git archive --format zip --output /full/path/to/zipfile.zip 2.0  </span><span style="color:rgb(0,0,0);font-size:14px;line-height:18px;background-color:rgb(255,255,255)">and just unpack it on the webserver.  This would be much easier then having different repos to clone and export from.</span></font></div>

<div style><br></div><div style><font color="#000000" face="arial, helvetica, sans-serif"><span style="font-size:14px;line-height:18px">git is just part of our workflow now and IMO should be used for this.  The main thing is just abstracting away a lot of the git mess into simple to run scripts.</span></font></div>

<div style><font color="#000000" face="arial, helvetica, sans-serif"><span style="font-size:14px;line-height:18px"><br></span></font></div><div style><font color="#000000" face="arial, helvetica, sans-serif"><span style="font-size:14px;line-height:18px">- Nathan</span></font></div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 1, 2013 at 7:17 PM, Richard Duivenvoorde <span dir="ltr"><<a href="mailto:richard@duif.net" target="_blank">richard@duif.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 01-04-13 10:50, Paolo Cavallini wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I understand the reasoning, and I agree that wating translators time wouold be a huge<br>
mistake. I think the approach Diethard suggest will put serious limitation to the<br>
flexibility of the process. I think it is quite common for translators to find<br>
mistakes in the sources, and waiting the next release to fix them is an heavy burden.<br>
Could we think of a backporting system?<br>
</blockquote>
<br></div>
I proposed this earlier, but to be honest, I have the feeling that a translating process is not fitting in the normal github source code model.<br>
<br>
I think it would be easier to NOT create github branches for every major (I mean 1.8 2.0 etc) version, but just copy the documentation tree (or at least the desktop-appliation/python cookbook/<u></u>otherversionspecificedoc sources) and have a copy for every version in master in Github.<br>


<br>
-1- This makes it voor Github novices easier to see there are more versions of the docs in the tree (as they SEE 1.8 2.0 and master in their clone/checkout).<br>
-2- This makes it easier to deploy everything at once on the webserver also<br>
<br>
Downside is:<br>
-1- we have to update the scripts to handle this every version<br>
-2- there is a lot of redundancy in sources of the desktop<br>
<br>
But it makes the proces easier and more transparant for non coders, and also easier to do parallel translation/fixing of docs for older versions.<br>
<br>
Feel free to disagree and tell me :-)<br>
<br>
Regards,<br>
<br>
Richard<div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
Qgis-community-team mailing list<br>
<a href="mailto:Qgis-community-team@lists.osgeo.org" target="_blank">Qgis-community-team@lists.<u></u>osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-community-team" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/qgis-<u></u>community-team</a><br>
</div></div></blockquote></div><br></div>