Re: Breaking BC / Changing API / Deprecating

Joe Stump wrote:

OK, then someone answer a few things the RFC doesn't address. 1.) If a package has a 0.2 stable release, but no stable release over 1.0 can I break BC and make API changes? According to the RFC I can break BC within 0.*.* series and, since the package's 1.0.1beta was never stable this rule should still apply (btw, I'm talking about Net_Curl). As no stable 1.0.0 release was ever made should I not be able to break BC and/or change the API? If I don't break the API, but merely deprecate the stuff and it still behaves as normal then there shouldn't be any issues.

The regulation IIRC is most concerned with the first stable release. This is by definition 1.0.0 .. packages that are too old to follow this rule will be decided on by the QA team on a case by case basis.

2.) If a package goes from Foo_Bar to Foo_Bar2 how long must Foo_Bar be maintained?

As long or as short as you please. If there is demand someone will get the opportunity to pick up the ball if the original maintainer has dropped it.

3.) Are classes in Foo_Bar2 still just Foo_Bar or are they Foo_Bar2? If they are Foo_Bar2 then how does this not break BC?

Its a BC break, the point of a new major version is to break BC. And at the same time it isnt a BC breaks since its a new package for all intends and purposes! regards, Lukas