Version Number of Upcoming Release

[Bart Cerneels]

On Fri, Feb 5, 2010 at 08:31, Mark Kretschmann <kretschmann at kde.org> wrote:
> 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

True. But the problem I'm facing is having made promises for the 2.2.3
release that I won't be able to keep. A longer release cycle would
have allowed me to include these features.

How about putting these on the 2.3 release plan: Collection & Playlist
Synching to UMS, MTP and iPod devices? But we really need a big team
effort to get something decent. There sort of is a backend, I'm
working on the subtle GUI elements, but there is more advanced GUI
work that other people are a lot better at.

Bart