Re: XML_Tree - Lets Fix this up finally

Looking at this, athough it may be nice to do something like: xxxx 1.0 xxxx 2.0 xxxx 3.0 xxxx4 4.0 (big bc break release) Pros on renaming to xxxx2 on major overhall but theoretically non-BC breaking code. - Frequently, someone may have depended on the structure you previously defined and 'extended' based on the existing code (example one of the Pager Classes, where went from a single class to a factory method, and ended up making code I wrote that extended it totally unusable..) * this is really the unintended result of thinking that you are really BC even though you are not. - If you are really confident that it isnt BC breaking - then what is the benefit in calling it 2.0.0 rather than 1.20.0 .. other than 'I like 2.0'? - Guareentees code compatibility, if your code worked with 1.* then it will always work with 1.* Cons - Less obvious to end user that there is an upgrade path. (although the fact that the old package isnt documented is probably a big hint) - Our package browser doesnt currently 'link' the new/old together (on the Todo list?) I think basically for me the Benefits of this outweight the Costs. From a users point of view, I'd rather be certain that my applications work with a specific codebase, than let a component be upgraded, and at the authors whim break all my applications. (This has happened quite a few times already, and it doesnt exlude my packages...) Regards Alan Arnaud Limbourg wrote:

I think alan's suggestion makes sense. The package has a beta state anyway. General question though, following what justin said, nothing prevents you from releasing a Package 2.0.0, if you keep BC but heavily modify internals you may want to do that and this does not require Package2 to exist, right ?

I believe that every major number revision is supposed to be a new package. If it doesn't break BC then, logically, it *should* be ok to have it as the same package, but this could (would) cause a lot of confusion as you wouldn't nevessarily know where to go for V2 of a package. I would suggest (if it's not in the RFC already) that all major revisions must be a new package.

I don't really see the value of doing that. I mean Foo 2.0.0 Foo2 1.0.0 is not confusing imho since they are different packages. My point is that we should avoid having rules when they don't bring much. Arnaud.