[Kst] Kst 2.0.0 rc1

Peter Kümmel syntheticpp at gmx.net
Thu Aug 12 12:20:25 CEST 2010


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
> order.
> 
> 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
> everywhere.
> 
> 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).
> 
> Thoughts?

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.

Peter


P.S.:
Also KDE 4.0 was more a "usable beta" than a release.






More information about the Kst mailing list