Why have you set the alpha version as the current 5.x release

I have posted this reason a few times, and the basic idea is that because I am trying to get this release out before Drupal 6, so I did this to help get more people to test this for the truncated timeframe.

The messages that you are seeing is a bug in update-status where it should be ignoring the 4.x series other than listing it as a an alternate version, and just show the newer versions for the 3.x series.

According to dww at the "badcamp", it's not a bug in update_status, rather ecommerce should not choose an unstable branch as the default branch.

I would say, let's use other means to encourage testers rather than setting the default branch prior to release.

It is a bug in update_status, because if you are on v3 it should not be telling you that you need to upgrade to the next major version. It should only tell you to upgrade to the next minor version and inform you that there is a new major version.

Also the project module will not let you have a different major development version to the current major version, so you can't have a drupal 5.x v3 stable and a drupal 5.x v4 development.

This is a problem with update_status forcing people to upgrade major versions which is usually not a good idea, without a lot of prep work, where as a minor version will usually just drop in without issue.

it could at least be a feature request. apparently dww considers update_status to be working as intended at the moment: if a new branch is selected as the default version, then update_status will notify admins to upgrade (this is useful in cases where a new branch obsoletes an older branch). is there an issue filed on this?

But even if the previous branch is a is not being worked on, it is generally is not a drop in replacement. If you are going from v2.1 to v3.4 is not going to be a drop in replacement. You are going to need to do a lot of prep work, where as going from v3.3 to v3.4 is generally going to be a drop in replacement.

So update status should not through an error is there is a newer major version, but it should indicate that there is a newer version, which it does now.

update_status will alert users to upgrade (possibly via daily emails, if so configured) if there's a release on a different major version number which is set as the "default" major version.

If you really want to set an alpha version as the default version without scary warning messages issued by update status then some sort of additional configuration & functionality has to be added to project release & update status modules. I.e. some way to make update status warnings for releases on the default major version optional for installations on different major versions.

That is fine if you feel this is best for you.

I have reasons for doing this which I have explained here and elsewhere, to get over the short term issue where I need as many people as I can to test and debug e-Commerce, and this is a solution to my problem.

gordon, could you please clarify what is the stable version of ecommerce? that will work for adding sales tax, shipping and paypal? and if we've tried a v4 alpha version and need to go back to v3 how is this done?

@Gordon: it's not a bug in update_status. You, the maintainer of e-commerce, have selected 5.x-4.* as your "recommended version". update_status is just following orders. Normally, it'd never warn people to upgrade to 5.x-4.0-alpha if it was available and 5.x-3.* was the recommended branch. However, that's not happening, since you've told the world (and update_status clients everywhere) that 4.0-alpha is recommended.

That's not what you mean. You mean "5.x-3.* is stable, but if you can, please test 5.x-4.0-alpha". That's not what you're saying by your actions.

update_status is behaving exactly as designed. The bug is in your choice of "4" as the recommended/default major version for 5.x core...

Granted, it's too bad that project.module doesn't have a similar UI as update_status, where it could display 5.x-4.0-alpha as "Also available" in the download summary table directly on the project node. See http://drupal.org/node/176776 and http://groups.drupal.org/node/6186 for more. However, that's *not* a bug in update_status, either. As a work-around for this minor UI hassle, you can always mention the 5.x-4.0-alpha in the body of your project node, and include a link to the release node.

But, it's irresponsible to set an alpha release as the "recommended" version of your module, and it's causing havoc for people who use e-commerce and update_status, not due to a bug in the tools, but due to your own misunderstanding of how they work.

Cheers,
-Derek

Sorry, to further clarify:

a) Yes, a jump in major version can be a big switch, it's up to the maintainer. That's the point of having a "recommended major version" ("recommended series" if you prefer). You should only change the recommended series if you think it's time for everyone to make that switch. If update_status didn't have a mechanism for maintainers to alert update_status that "1.* is now abandoned, people should upgrade to 2.*", we'd be screwed. So, I built in that mechanism -- via the recommended version on the project node.

b) Aside from the recommended version, update_status always sticks to doing logic on whatever major version you're currently on. If you're at 5.x-3.4, and 5.x-4.1 is out, so long as 5.x-4.* isn't recommended, update_status would only warn you to upgrade once 5.x-3.5 is out. However, if you're already at 5.x-4.0, it'll warn you to upgrade to 5.x-4.1, even if 5.x-3.* is still "recommended".

The WHOLE POINT of the default/recommended major version setting is to give you a way to "pull the trigger" when you really think it's time for your users to upgrade. We need to have a mechanism for that, and this is how it works.

I'll be the first to admit that none of this is well documented anywhere yet, which is part of the motivation for why I gave that talk at the bay-area drupal camp (badcamp) in the first place. So, I'm not blaming you for being confused. But, now that you know, you really should fix it. ;)

Cheers,
-Derek

Ok, point taken.

But how is this going to work when Drupal 6 is released. Drupal 6 will be the recommended version, but Drupal 5 is still fully supported, is every Drupal 5 install going to through an error to upgrade to Drupal 6?

A lot of people may not be able to upgrade to Drupal 6 on Day 1, or maybe not even for 6 months, and this error is going to sit there., and this will have a flow on effect as all the other contributed modules will through this error as they will change versions.

Upgrading core is an utterly separate question. Each version of update_status only asks about versions of modules (and in D6 and beyond, themes) that are compatible with the same version of core that the client is currently running as. So, no matter what happens, a 5.x-* update_status client will never tell you anything about 6.x-*. It's always a vastly bigger deal to upgrade core, and notifications related to that are completely outside the scope of what update_status tries to accomplish.

Meta comment about the release system: everything is segregated by the "Drupal core compatibility" taxonomy terms. Basically, each version of core you support is as if it were an independent project: you can have multiple branches, versions, whatever. This is more conceptual than technical, but technically it's also true in many ways (e.g. with the behavior of update_status, the project browsing pages, the table of available releases on the project node, etc).

Cheers,
-Derek

This is my point, Major versions should be treated as separate versions entirely.

In the next month or so e-Commerce will have 2 stable versions for Drupal 5.x and people should not be forced to upgrade to the next major version just because I have set v4 as the preferred version.

This will happen in Drupal 6 as well, because once v4 is out we will be porting v4 to Drupal 6, and then creating a v5 branch to continue development forward on a Drupal 6 only version, which will be out before Drupal 7. Again having 2 stable versions in a single Drupal release.

Once e-Commerce v4 is out we will still be supporting v3.x for both 4.7.x and 5.x. Other than getting new features and being more flexibility there is no reason for people to upgrade to v4. No new features will be going into v3.x but bug fixes and security updates will still be done.

So why should update_status though errors saying that people should upgrade?

Gordon.

You've certainly got a point there. Given how most contrib maintainers operate, I thought it was enough of a miracle to expect a stable vs. a development branch. You're talking about multiple stable branches for each version of core, which is totally reasonable, but not something I fully expected when designing and implementing the update_status integration. Perhaps we need to more directly expose major versions throughout the code and UI of project*, including taxonomy terms to describe what state a given branch is currently in. This came up in my BADCamp talk, in terms of clearly stating your intentions as a maintainer. It'd also be incredibly handy for searching the issue queue by major version. update_status would have to know about this, too, so that it would only tell you to switch major versions if the "maintaining bug fixes" term switched to "unsupported" (or "abandonded", or whatever we decide) for your current major. It'd also have implications for how we display things on the front page of the project node in the available releases table.

The D6 port of project* looms very large, and is a top priority for us. On the other hand, if we're going to change update_status at all, we'd have to be very fast to get it into D6 (now that it's in core). We're probably too late already, though I might be able to convince Dries/Gabor this was essential if we were going to make a concerted push to get it done soon. At least it wouldn't change the core API at all, just some of the functionality and UI of the update.module.

@brmassa: I think that's a very bad decision, but it's your module. It's just a shame, since eCommerce is one of the large, important module suites that lots of people depend on, so it's important for those of you maintaining it to be as responsible as possible. Just because you disagree with how the tools currently work doesn't mean you should disregard them. Especially since update_status is part of core in D6, it's going to be essential for module maintainers to learn how their actions directly impact their users like this.

Also, note: the question of multiple stable branches doesn't at all impact the fact that you've marked an unstable development (alpha) series as your "recommended version"...

@dww: i know you are bussy, but case http://drupal.org/node/179103 could be a good reference about the way how the system must be used from now.

Yes this has gone on longer than we expected, but the reason for doing this is still I feel valid. I needed, and still need for people to test and as much as possible. And having this as the preferred version ramps this up a substantial amount.

But the fact still remains in which I still believe is a bug or an oversight is that once ec4 gets releases we will have 2 stable versions on Drupal 5 and according to update status people will have to upgrade to version 4 when v3 is still a fully maintained stable branch.

If update status treated major versions are independent versions and not force the upgrade, but indicate that there is a newer version this would not be the big issue that it is.

@gordon: See http://drupal.org/node/196652#comment-645046 -- Yes, it'd be nice if project* and update_status could handle multiple supported branches for a given version of core. But, that's not how it currently works, and without a lot of help or sponsorship, it's not going to change anytime soon. Therefore, eC is going to have to use the tools you have, given how they're currently designed and implemented, not how you wished they work. So, for now, the "right" thing to do is to put the "oldest" supported branch as the recommended version, and add text in the body of your project node to point to the other branches you care about. A relatively simple change that wouldn't require messing with update_status is http://drupal.org/node/176776.

@gordon: i don't know if someone tried to build the "Automatic update" module yet, but many people requesting this feature.

If such a module becomes or is available - sites are automatically upgraded without user interaction. If you mark an alpha as your recommended release - whatever branch this will be and if we have the feature dww described above or not - sites get's automatically upgraded to this untested and buggy alpha version.

Then, i wouldn't like to be in your shoes...

My point is that soon there is going to be 2 stable version of e-Commerce, and no reason for people to upgrade from v3 to v4. ANd if there is an automatic update module it should *not* upgrade major versions.

This is where my complaint of the current update system is. Even though the current version is alpha it should not be forcing people to upgrade from v3 to v4.

In the next little while this will change and v4 will be stable, but v3 will still be fully supported. Major versions should not be automatically updated automatically.

@gordon: to shorten this - simply don't mark an pre-release as recommended version any we are all fine. Whatever your wishes are - the current way is how this system and tools work... but if you don't like the way it works - jump in and create patches for project* as dww already said, but don't make things different if the system do not support this, please.

I have my reasons for doing this, and I feel they are still valid. But either way I am still screwed, since when v4 becomes stable we will be back in exactly this situation that we are in now.

Update status is going to demand that they upgrade to v4 since v4 has a security release fix on it, even though v3.4 has that exact security fix applied.

So if I am to change the project as suggested, as soon as v4 is released we are stuffed again, mainly because update_status doesn't allow for more than 1 stable release per Stable release of Drupal.

e-Commerce is going to have multiple major versions in a single release of Drupal. But people running v3 will have update_status demand that you upgrade to v4.x even though there is no release to (except for new enhancements). But fixes and security updates are still being made to v3.x, and and will be until v5 is released.

Also I am going to have this exact problem in Drupal 6 since we will have 2 stable versions of e-Commerce once v5.x is released. We are working hard to get a head of the curve by being behind. So by the time Drupal 7 is released we will be releasing a stable version of e-Commere on the same day, not 6 weeks later, like previous.

Basically we will create a release of e-Commerce for the current stable version of Drupal and then port this version to the next release of Drupal. Once this is complete we will then start on the next development version which will be the next stable version of Drupal. So in this case we are developing v4 for Drupal 5, and then once we have released this we will port this to Drupal 6. Once this has finished we will start v5 of e-Commerce for Drupal 6.x, and get it released. Then we will get v5 working for Drupal 7.x and release on or soon after the release of Drupal 7.x and then so on.

And we will always provide support for the current version of e-Commerce and the previous version. So in this can we are providing support for v4 and v3, so update status should not force people to upgrade to v4 if they are on v3.

@gordon: Yes, we understand your reasons, but I'm sorry, they're not valid. ;) You want alpha testers to know about the v4 alpha series. Making your alpha release the officially recommended version, simply so it's more visible on the project node, is not valid, given the implications for update_status, etc. Even with the current tools, you're not screwed, even once v4 is supported, not alpha. Just leave v3 as the recommended version, and have v4 also visible on the project node. Then, update_status won't complain at all for anyone. If people are running v3, it won't tell them to upgrade. If they're running v4, it'll only tell them to upgrade when there's a new v4 release. For now, the way to make both visibile is a link in the project node's body. If I could stop arguing about this stuff and get back to writing code, http://drupal.org/node/176776 would be a relatively simple solution to making both v3 and v4 visible on the project node without a manual link.

See http://groups.drupal.org/node/7440 for a proposal for a complete solution to all of this.

How do I know that version 5.x-3.x is fully supported? There is not a single word about it on the project node.

The current system supports only one Official (recommended) version, so please choose it wisely.

can I chime in my 2 cents here?

ecommerce is a great suite of modules but you guys should really change the default link to be the stable version. I made the mistake of trusting the Drupal default (i.e. the module download links to the most stable version) and was well and truly snookered when I tried to set it up.

I understand that a huge amount of time and effort has gone into ecommerce and I don't mind the extra time I spent trying to get it working only to realise I had downloaded a development version (I assumed I had done something wrong), but, for newcomers to Drupal, it must be extremely off-putting.

phil

Releases and Update Status Handbook
http://drupal.org/node/197584

Never make an alpha recommended.

subscribe