The releases after 2.0 and string changes..

Seb Ruiz ruiz at kde.org
Thu Dec 4 21:55:26 CET 2008


2008/12/5 Mark Kretschmann <kretschmann at kde.org>:
> On Thu, Dec 4, 2008 at 3:12 PM, Dan Meltzer
> <parallelgrapefruit at gmail.com> wrote:
>> It seems clear to me that we have a lot of string tweaking to do after 2.0.
>> I don't think it's fair however to expect translators to keep up with a 1-2
>> week release cycle for our first point releases.  I'm not exactly sure the
>> best way we can handle this..
>>
>> I'm wondering if we should immediately branch 2.0, keep it string frozen,
>> and just do bug fixes in it while starting 2.1 development in trunk and
>> planning a 2-3 month development cycle for it (short enough so that the
>> missing strings are not missing forever, long enough to still allow for
>> features).  I think this would be acceptable as many of the 2.1 features we
>> have talked about are already implemented and sitting in developers git
>> branches, allowing a whole bunch of changes to land post 2.0.  I think this
>> would also allow us to keep 2.0.x fairly stable (as we all want to get our
>> new features in after 2.0 is released, but I don't know if it makes sense to
>> put all these features in 2.0.x)
>>
>> The downside to this is that we probably will stop using 2.0.* on a
>> day-to-day basis, and would have to have two checkouts in order to make
>> bugfixes (though you can set up git to have branches that point to different
>> places in svn, which would reduce the amount of different checkouting.)
>>
>> Thoughts?
>
> The plan that I, Nikolaj, and a few others had discussed on IRC was to
> keep 2.0 as trunk for about 3 weeks after release, so that we can all
> focus entirely on bug fixing. If we branch immediately, we'd be forced
> to backport, and that never works out very well in reality.
>
> We would then do a 2.0.1 and maybe 2.0.2 release from trunk, and after
> that branch.

Why can't we simply revert to the 1.4 release model? I like the idea
of simply piling straight onto 2.0, features, bugfixes and all.
Translations would suffer, but this is something that we've always
dealt with and would become less and less of an issue as time passes.

I don't want to have to wait another 6 weeks to start developing
features and getting them into trunk and tested.


-- 
Seb Ruiz

http://www.sebruiz.net/
http://amarok.kde.org/


More information about the Amarok-devel mailing list