[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