Hi folks,

I've just realized that I might have messed up naming the current D7
development branch 1.x.

Having looked at other modules' way of handling version numbers, I now
understand that 7.x-1.x is not necessarily newer than 6.x-1.x. In fact
they are supposed to offer the same feature set and generally be
equivalent short of the Drupal core compatibility.

Now that we are going to backport the current 7.x-1.x code to 6.x, I
need to decide the best way to solve the problem created by my
mistake.

Since we already have 6.x-1.x stable releases, and simply bringing
6.x-1.x up to date with 7.x-1.x would confuse things even more, I
suggest that the next release of the D7 module (after 7.x-1.0-rc1) is
named 7.x-2.0 and the current 7.x development branch tagged 7.x-2.x.

This way we can backport the code and release it as 6.x-2.0, making
the two branches compatible with each other in terms of feature
sets/version numbers. And pretend that the 7.x-1.0 releases - beta1 and
rc1 - were actually 7.x-2.0-beta1 and 7.x-2.0-rc1, respectively.

Please let me know what you think.

Cheers,
George

Comments

BenK’s picture

BenK commented

George, this makes good sense. Yes, when we started all of this, we forget to consider the naming conventions of the D6 backport. And since there are API changes, it makes sense to create 7.x-2.x and 6.x-2.x branches.

Just one suggestion: I think the next release of the D7 module should be 7.x-1.0-rc2 (not 7.x-2.0). There are enough issues/features that need to be cleaned up in rc1 that I don't think we're quite ready for a totally stable version as the next release. I generally prefer to have at least one release candidate with minimal fixes before going stable. That being said, if all looks good in rc2, we might be able to release 7.x-2.0 right after (like maybe the next day).

--Ben

geokat’s picture

geokat commented

OK, thanks, Ben.

geokat’s picture

geokat commented
Status: Active » Closed (fixed)