[kwave] /: prepared for next release, v0.9.3, at 2017-01-29

Ben Cooksley bcooksley at kde.org
Sun Jan 8 21:49:00 UTC 2017


On Mon, Jan 9, 2017 at 8:01 AM, Albert Astals Cid <aacid at kde.org> wrote:
> El diumenge, 8 de gener de 2017, a les 11:26:20 CET, Thomas Eschenbacher va
> escriure:
>> Hello Luigi,
>>
>> sorry, I didn't know about that!
>> I searched through the KDE web sites, but found nothing about this topic.
>
> Which topic?
>
>>
>> For the moment I reverted the change to the docbook file only.
>>
>> It is fine for me to follow the KDE release cycle and abandon the
>> old/own release scheme. But, to be consequent, there are some more
>> places to consider. It would be great to get some hints about how to I
>> handle these...
>>
>> 1) help_en.docbook
>>
>> -> is it ok and sufficient to just remove the old version, so that it
>> reads like this:
>> "<releaseinfo>Applications 16.12</releaseinfo>" ?
>>
>> -> should I rely on the release team to update this information when
>> needed, or do I have to take care about that in my build system / scripting?
>>
>> 2) kwave.lsm
>> -> does it still make sense to keep that file, or should I remove it?
>
> Up to you, but AFAIK we don't ship many of those lsm files, they're kind of
> considered old school/deprecated.

LSM files went the way of the dinosaur a long long time ago.
They're certainly not used for package uploads anymore.

>
>>
>> 3) README
>> -> same as for kwave.lsm, remove it?
>
> Up to you, does it say anything interesting?
>
>>
>> 4) filling KAboutData and app.setApplicationVersion(...)
>> -> any reference implementation about how to fill in the version field?
>>
>> 5) build system
>> -> is there any cmake variable that I can use, just in case I need the
>> application version number?
>
> There's no such thing as "the application version number", that's something
> you define, if you *want* to follow the KDE Applications versioning you can
> read https://community.kde.org/Guidelines_and_HOWTOs/Application_Versioning or
> you can do an hybrid like in
> https://cgit.kde.org/okular.git/tree/CMakeLists.txt
>
> Cheers,
>   Albert

Cheers,
Ben

>
>>
>> regards,
>>    Thomas
>>
>> Luigi Toscano wrote:
>> > Thomas Eschenbacher ha scritto:
>> >> Git commit 85463c19f2b011ece59e920ac06c03f2fc749d39 by Thomas
>> >> Eschenbacher.
>> >> Committed on 06/01/2017 at 13:11.
>> >> Pushed by eschenbacher into branch 'master'.
>> >>
>> >> prepared for next release, v0.9.3, at 2017-01-29
>> >>
>> >> M  +1    -1    CHANGES
>> >> M  +6    -6    README
>> >> M  +1    -1    VERSION
>> >> M  +5    -5    doc/en/index.docbook
>> >> M  +2    -2    kwave.lsm
>> >
>> > Hi Thomas,
>> >
>> > kwave is part of KDE Applications, which means that you don't have your
>> > own
>> > release cycle anymore. This was explained when you requested to join KDE
>> > Applications.
>> > The next patch release of KDE Applications (so only bug fixes) will be
>> > tagged next Monday:
>> > https://community.kde.org/Schedules/Applications/16.12_Release_Schedule#Mo
>> > nday.2C_January_9.2C_2017:_KDE_Applications_16.12.1_tagging
>> >
>> > And the next major release will be around April (schedule not fixed yet).
>> >
>> > If you want to keep your release schedule and do your release when you
>> > like, you can certainly do so, but then kwave should be moved to
>> > extragear.
>
>


More information about the release-team mailing list