Version Number of Upcoming Release

Mark Kretschmann kretschmann at kde.org
Fri Feb 5 08:31:10 CET 2010


On Thu, Feb 4, 2010 at 11:10 PM, Dan Meltzer
<parallelgrapefruit at gmail.com> wrote:
> On Thu, Feb 4, 2010 at 1:59 PM, Bart Cerneels <bart.cerneels at kde.org> wrote:
>> On Thu, Feb 4, 2010 at 19:05, Mark Kretschmann <kretschmann at kde.org> wrote:
>>> I was wondering what version number we should use for the upcoming
>>> Amarok release. Originally, the plan was to call it "2.2.3". I still
>>> think that's completely fine from a developer's perspective (because
>>> with Git, any release really just becomes a snapshot, more or less).
>>> But maybe this would be a good chance to gather some extra PR, for
>>> free.
>>>
>>> We could simply call it "2.3", as this release sports a number of
>>> important changes. Most visibly that would be the toolbar, which looks
>>> very different from older versions. So I think we could justify the
>>> version jump, especially because it really is "just a name":
>>>
>>> Whatever we change this version string to, be it "2.2.3", "2.3",
>>> "WISTA Ultimate Edition", etc, it's basically just a name anyway. We
>>> could simply go to "2.3", without causing a huge work overhead.
>>> Everything else would stay as it is now (same splash screen, same
>>> everything). So, if this can get us some extra PR, methinks, we might
>>> as well use this chance :)
>>>
>>>
>>> What do you think?
>>>
>>
>> I would prefer to add some more features. Perhaps if we made the cycle
>> twice as long before releasing a "feature" (dot) release some of us
>> would actually have a chance to add new things. I'm also considering
>> pulling some features I added in this cycle because they are just not
>> done yet.
>
> Thats the idea behind the rapid releases.  You develop a feature in a
> branch, and push it to mainline when it is ready for polish.  If a
> features not ready for a release and was merged, you back it out and
> then re add it once the release is tagged.  We could have a schedule
> twice as long, and you could still run into the issue you are talking
> about.

Exactly. No matter how long you make the release cycle, it doesn't
change the development model in fundamental ways. Git is the game
changer here.

If we extended the cycle by one month, it would be pretty much the
same thing as it is now. Except, we'd have a longer cycle.

-- 
Mark Kretschmann
Amarok Developer
Fellow of the Free Software Foundation Europe
www.kde.org - amarok.kde.org - www.fsfe.org


More information about the Amarok-devel mailing list