Releasing a 2.0.2...

[Dan Meltzer]

On Tue, Feb 10, 2009 at 2:13 PM, Mark Kretschmann <kretschmann at kde.org> wrote:
> On Tue, Feb 10, 2009 at 4:33 AM, Dan Meltzer
> <parallelgrapefruit at gmail.com> wrote:
>> We currently have 72 open bugs targeted for 2.0.2, but I don't see
>> much interest in fixing them... I think we should think about
>> releasing a 2.0.2 anyways.  The ChangeLog for 2.0.2 currently looks
>> like this:
>>
>> VERSION 2.0.2
>>  CHANGES:
>>    * Show a statusbar message when loving a lastfm track.
>>    * Show error message when Wikipedia information cannot be retrieved.
>>
>>  BUGFIXES:
>>    * Open ogg files in Amarok when using Dolphin and other file managers.
>>      Patch thanks to Lubos Lunak <l.lunak at kde.org>. (BR 180155)
>>    * Fix podcast episodes not ordered right because of incorrect parsing of
>>      pubdate. (BR 181338)
>>    * Fix crash in tagdialog when editing tracks without an artist. (BR 183180)
>>    * Statistics were not calculated properly in all instances. (BR 182025)
>>    * Compilation fixes on Open Solaris.
>>    * Trim URL before adding a new podcast.
>>    * Add Ok button to the podcast configuration dialog to improve usability.
>>      (BR 181339)
>>    * Add tooltips to now playing widget icons.
>>    * Fix not possible to download episodes from newly added podcast channel.
>>      (BR 180851)
>>
>>
>> I think theres enough there to merit a release in the next few weeks.
>> I do think that we should pay some attention to the bugs open against
>> 2.0.2, and am willing to backport any commits that people make in
>> trunk that should be backported (If you don't have a stable checkout,
>> fex).  Please CC me in the commit if you want me to do this.
>>
>> Open bugs targetted for 2.0.2: http://tinyurl.com/amarok-202
>
> Backporting and releasing another 2.0.x version is great, we all agree
> about this, right?
>
> While it is great indeed, here a few words of caution (from
> experience): The one big danger with backporting (the style we are
> doing it) is causing regressions in the stable branch. And that, my
> friends, is not something you want.
>
> You can be as careful as possible, every commit carries the danger of
> introducing a bug accidentally. So you need testers (a group of
> dedicated users or developers, permanently testing the branch - we
> don't have that. And/or you need automatic code testing ("unit
> testing") - we don't have that (yet).
>
>
> That's basically all I wanted to say. Think about it. Discuss.

Sure, however, in that list (which is pretty much everything that has
been backported) there is nothing signifigant that would cause
regressions that hasn't also been tested in trunk.  I'm not sure about
the podcast stuff (Bart could say more about that--I don't use it) but
other than that, the only thing in the list that could possibly cause
a regression is the scoring stuff, and that's been tested in trunk
(and backported exactly as it is there)--It is far more accurate (as
in, it actually works) than what was there previously.

While it's true that we need to avoid releasing a program thats worse
than the current version, I do not believe that "Fix a possible null
pointer deref" or "Add an Okay button to a dialog" or "Add tooltips to
now playing icons" are going to cause our software to be worse than it
was originally.

Dan,
>
> --
> Mark Kretschmann
> Amarok Developer
> www.kde.org - amarok.kde.org
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>