The releases after 2.0 and string changes..

Dan Meltzer parallelgrapefruit at gmail.com
Thu Dec 4 15:39:36 CET 2008


On Thu, Dec 4, 2008 at 9:37 AM, Gary Steinert <gary.steinert at gmail.com>wrote:

> For the new features I'm with you. I don't think the small string changes
> should have to wait until 2.1 though. I think keeping any new features out
> of
> 2.0.x should reduce the pressure on the translators, and will benefit the
> 2.0.x users until we release 2.1.


The issue is that we want to release point releases every couple of weeks.
There are a lot of string we want to change/add.  I don't think that we can
expect translators to keep up with 2 weeks for string changes if we go about
adding all sorts of them.

>
>
> Also, instructions for getting git to point to two separate repositories
> would
> be very welcomed =P
>
> Gary Steinert
>
> On Thursday 04 December 2008 14:12:53 Dan Meltzer 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/amarok-devel/attachments/20081204/2d18b450/attachment.htm 


More information about the Amarok-devel mailing list