The releases after 2.0 and string changes..

[Nikolaj Hald Nielsen]

Basically what you are proposing is the KDE4 model. This has been
discussed before, and I think this might work, although I would like
to see one small modification. I say we do one or two 3 week release
cycles for 2.0.1 and 2.0.2 in trunk and then branch off stable. The
upside of this is that everyone will be running the stable version for
a little while and we can focus on getting some bugfixes in. The
downside is that it will delay the "new feature frenzy" a little, but
is this really a big issue since everyone seem to have these features
cooking in their private git repos for now?

- Nikolaj

On Thu, Dec 4, 2008 at 3:12 PM, Dan Meltzer
<parallelgrapefruit at gmail.com> wrote:
> Hi,
>
> 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?
>
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
>