Re: Versioning (resent AGAIN due to lack of replies)

On Mon, 17 Sep 2001, Stig Bakken wrote: >On Mon, 17 Sep 2001, Stig Bakken wrote: >> On Sun, 16 Sep 2001, Sander Steffann wrote: >> > > >> > > GD_EXT_VERSION = 30201 >> > >> > Very big +1 on this one (or something similar). What also would be useful is >> > a built-in way to determine optional parts of extensions, like something to >> > check if GD supports GIF/PNG/etc. This way, you can check the version and >> > the optional parts. >> >> The PHP version is trivial to do, but what about extensions that are >> bundled today but that will be > >(sorry for the interruption) ... de-bundled in the future. What version >scheme should they follow? Today using the PHP version could make sense, >but preparing for a de-bundled existence each extension should have its >own versioning scheme. > > - Stig > To clarify, everything should follow same rules but the numbering of course is different. ie. PHP 'core' version is 4.0.7 but extension version can be 2.0.3. EXPERIMENTAL extension versioning: v = 0. ie. 0.x.x This would mean that when the extension is considered stable, the major number is pumped to 1. Proposed versioning rules (both core PHP and extensions: -------------------------------------------------------- v.m.b (e.g. 4.0.8) v = Changes only when there are big BC breaking changes or when there are big portions of code rewritten, deprecated functions removed, functions behaviour changed..etc. m = Changes only when new functionality is added. No API changes. (BC) b = Bug fixes ONLY. No new functions added. No API changes. (BC) If this is 0, it is left out. BC = 100% backwards compatible. Betas: - add betax: v.m.b-betax (e.g. 4.1beta1) RCs: - add RCx: v.m.b-RCx (e.g. 4.2.1RC2) These rules are not only for the 'user-level' changes but for all changes that are not stricly internal. ie. this also affects Zend engine changes. Anyone writing extensions can trust that between major number (v) changes there won't be any API changes and their extension will work in 4.1.x and 4.5.x without any changes. Another issues is, should we have same kind of rule as e.g. Linux has ? ie. even minor number version is from the 'stable' (x.2.x) branch and the odd minor number version is from the 'development' (x.3.x) branch. Betas/RCs: ---------- Stig brought up (on IRC) the issue of betas, RCs. And having a special function, version_compare() will solve the problem in comparing different versions. (it will understand the schema) e.g. the function knows that 4.0.7RC2 < 4.0.7 Stig can explain this better. :) --Jani