As you all know I feel that backwards compatibility is important, and
have been striving not break existing scripts when making changes.
However, going forwards some things will have to change, and I thought
it would be worthwhile for me to outline my strategy for deprecating and
then removing/changing functionality. I would appreciate comments on
the following:
(1) When making a change backwards compatibility will be maintained
wherever possible. When a change in behaviour is desirable (for example
'use Win32::GUI;' not exporting 360+ Constants) then a release (in this
case 1.04) will issue a 'deprecated' warning stating that behaviour will
change in the future, and explaining what changes should be made.
(2) A subsequent release (depending on the gaps in the release cycle and
the severity of the change this might be the following release - in this
example 1.05) may change behaviour, but will issue a warning that the
behaviour has changed (may die instead depending on the change).
(3) A later release may remove the warnings.
(4) Release notes will have a section on deprecated/changed/removed
behaviour.
I think an approach like this is pragmatic (in most cases), giving users
at least 2 release cycles to fix their code, whilst not imposing too
high a burden on us maintainers to maintain backwards compatibility for
ever.
Regards,
Rob.
--
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/
