This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: proposed deprecation policy/mechanism
- From: Mark Wielaard <mjw at redhat dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Fri, 25 Jun 2010 20:24:28 +0200
- Subject: Re: proposed deprecation policy/mechanism
- References: <20100625153323.GA29501@redhat.com>
On Fri, 2010-06-25 at 11:33 -0400, Frank Ch. Eigler wrote:
> - deprecation
>
> Try to remain compatible with existing valid scripts, with respect
> to changes in the script language or the tapset. Where this is not
> desirable, preserve the old functionality using the %( systemtap_v %)
> preprocessor conditional in the tapset and systemtap_session.compatible
> in the translator. Warn of future depracation in the NEWS and stap.1
> file.
>
> Tapset functions to be deprecated should be kept for at least one
> major release.
Maybe we should also say something about how often we will create a
major release. Once around every 3 months?
> For example, if we're in development between versions
> 1.2 and 1.3, wrap to-be-deprecated tapset functions in
> %( systemtap_v <= "1.3" %? function foo() {} %)
> so as to preserve the tapset function during the life of the 1.3 release.
Would the same hold for probe aliases?
Does this mean that they are still supported when systemtap 1.4 is ran
with stap --compatible=1.2? If so, then it would mean that we can never
really remove some functionality.
> Script language changes that cause earlier valid scripts to become
> invalid should be opt-in (requiring --compatible=NEWVERSION) for at
> least one major release before becoming default. For example, test
> strverscmp(s.compatible.c_str(), "1.4") >= 0
> in the 1.3 release sources in order to activate the change.
Do we have any of such language changes at the moment?
Thanks,
Mark