<br><br><div class="gmail_quote">On Thu, Dec 4, 2008 at 9:37 AM, Gary Steinert <span dir="ltr"><<a href="mailto:gary.steinert@gmail.com">gary.steinert@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
For the new features I'm with you. I don't think the small string changes<br>
should have to wait until 2.1 though. I think keeping any new features out of<br>
2.0.x should reduce the pressure on the translators, and will benefit the<br>
2.0.x users until we release 2.1.<br>
<br>
Also, instructions for getting git to point to two separate repositories would<br>
be very welcomed =P</blockquote><div></div><div><a href="http://www.dmo.ca/blog/20070608113513">http://www.dmo.ca/blog/20070608113513</a></div><div></div><div>A few things to beware of:</div><div></div><div>1) You can't git merge between git branches that have different svn origins. It changes the parent when you git merge and git svn dcommit after that does all sorts of wacky things (you don't even want to know..) Use git cherry-pick to move commits between branches in this case.</div>
<div></div><div>2) You will either need to maintain two separate build directories or have to deal with a full rebuild every time you switch branch checkouts. My suggestion would be to use two build directories, and if you use the cmakekde alias, you can get really kreative and make `cb` check the git branch you are on and change to a different build directory accordingly. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<font color="#888888"><br>
Gary Steinert<br>
</font><div><div class="Wj3C7c"><br>
On Thursday 04 December 2008 14:12:53 Dan Meltzer wrote:<br>
> Hi,<br>
><br>
> It seems clear to me that we have a lot of string tweaking to do after 2.0.<br>
> I don't think it's fair however to expect translators to keep up with a 1-2<br>
> week release cycle for our first point releases. I'm not exactly sure the<br>
> best way we can handle this..<br>
><br>
> I'm wondering if we should immediately branch 2.0, keep it string frozen,<br>
> and just do bug fixes in it while starting 2.1 development in trunk and<br>
> planning a 2-3 month development cycle for it (short enough so that the<br>
> missing strings are not missing forever, long enough to still allow for<br>
> features). I think this would be acceptable as many of the 2.1 features we<br>
> have talked about are already implemented and sitting in developers git<br>
> branches, allowing a whole bunch of changes to land post 2.0. I think this<br>
> would also allow us to keep 2.0.x fairly stable (as we all want to get our<br>
> new features in after 2.0 is released, but I don't know if it makes sense<br>
> to put all these features in 2.0.x)<br>
><br>
> The downside to this is that we probably will stop using 2.0.* on a<br>
> day-to-day basis, and would have to have two checkouts in order to make<br>
> bugfixes (though you can set up git to have branches that point to<br>
> different places in svn, which would reduce the amount of different<br>
> checkouting.)<br>
><br>
> Thoughts?<br>
<br>
</div></div><div><div class="Wj3C7c">_______________________________________________<br>
Amarok-devel mailing list<br>
<a href="mailto:Amarok-devel@kde.org">Amarok-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/amarok-devel" target="_blank">https://mail.kde.org/mailman/listinfo/amarok-devel</a><br>
</div></div></blockquote></div><br>