[Kst] Kst 2.0.0 rc1
barth.netterfield at gmail.com
Thu Aug 12 19:18:15 CEST 2010
OK. Lets go with a release.
How time consuming are releases to do? Could we reduce it to running a script?
At the current rate of bug-fixing etc, users could probably benefit
from monthly minor releases (we do in BLASTpol through Steve's ppa).
Peter, can you make sure it gets pushed to the KDE servers?
On Thu, Aug 12, 2010 at 6:20 AM, Peter Kümmel <syntheticpp at gmx.net> wrote:
> Barth Netterfield wrote:
>> We need to think through our release plans.
>> There is a lot to be said for a release now:
>> I totally feel that kst2 is usable in a 'production' environment,
>> since we just used it full time for the BLASTpol integration. Most of
>> the paper cuts we experienced have been fixed (though Peter Milne just
>> reminded me of one today), so, a quick release of some sort is in
>> Secondly, there are some disastrously bad beta releases floating
>> around (the newest one on the KDE server is beta2, which really should
>> have been called Alpha 2) so we need to get these fully superseded
>> On the other hand, there are some fairly fundamental issues (besides
>> the odd bug or missing feature) that are still not resolved that might
>> prevent us from calling it "2.0":
>> -We have not worked out the treatment of absolute vs relative path
>> names for data sources in kst files, though we have a preliminary plan
>> in bugzilla. This could effect what ends up in a kst file, and we
>> want to make sure that a 2.0 kst file remains compatible with kst 2.13
>> five years from now.
>> -If we want kst to be a KDE app (and I think we do) we need to
>> KDEify kst. This means we need to be compatible with the KDE life
>> cycle ( http://techbase.kde.org/Policies/SVN_Guidelines ). In
>> particular, we need API docs for data sources and plugins, and we need
>> to pass the krazy checker. We have something like 1100 krazy checker
>> issues, ranging from the trivial, like missing email addresses in the
>> copyright sections, to the fundamental, like the fact that we don't
>> currently use KDE at all :-) This would ideally be handled before a
>> 2.0 release.
>> -When we do the API docs, we may find that there are some
>> improvements that would be good for the plugin's API before we lock in
>> with 2.0.
>> So: maybe the best approach is to fully release a 'usable beta', and
>> make sure it gets into the KDE servers, and on kde-apps now, and
>> continue to hold off on 2.0 until it is a true KDE4 app. At the same
>> time, Steve Benton has scripted up an ubuntu ppa which he updates
>> ~weekly from SVN. While we continue to improve things quickly, this
>> is an even better approach for ubuntu/debian users. We are
>> considering advertising this path as well (though we would need to
>> make sure that the version string is useful in the bug wizard).
> At the moment Kst2 is a Qt4 only application, and we are free to release
> it at any time. Especially for ubuntu/debian it is an advantage of Kst
> not being a KDE app.
> Integrationg Kst2 into KDE is a new feature we not even started yet. So
> we should not stop the release of Kst 2.0 because of a totally
> unimplemented feature.
> Therefore I think we should release Kst 2.0.0 now (after fixing the
> path issue) even if it is not a KDE app. Only this way we could replace
> all the buggy betas in all distributions. And it would give a clear sign:
> we are on track and not deadlocked in beta releases.
> We could clearly state: Kst will get a full KDE integration again
> with a later version (maybe 2.1).
> When we make Kst 2.0.0 a full KDE app we will delay the 2.0 release for
> several months because it would take so much time: 1200 krazy issues,
> introducing KDE classes, dependency to kde's devel libs, translation,
> reviews, build system(?), API docs.
> Also KDE 4.0 was more a "usable beta" than a release.
> Kst mailing list
> Kst at kde.org
C. Barth Netterfield
University of Toronto
More information about the Kst