Differentiate between update and upgrade on module settings page

[owzim]

• Update for bug fixes and small feature additions.
• An upgrade might introduce breaking changes, the user should be informed about that.

Perhaps add an additional field somewhere (dunno where and how yet) where the module author can define a breaking changes notice or something.

So if a user clicks upgrade, the notice is fetched from the modules directory and thrown at the user.

Just my initial ideas about that topic.

[Nico Knoll]

+1

[Joss]

I think that if a new version is released that would break a previous version for whatever reason, then that should be listed as a unique version, even if a note is placed on the old version saying there is a newer version. Strictly speaking, that is probably neither an update or an upgrade.

I get confused between the two terms anyway, as does everyone else, from reading around the net. For instance with Debian you update the listings then upgrade the version - but the upgrade does not (or should not) break the usage of the previous and might only be minor. But software will often be announced as "the latest update" in press releases, the difference normally being described as "major" or "minor."

Either way, you are right, there should probably be something in the system to allow a bit more information or flags.

[teppo]

+1 for the idea.

For the implementation, I'd suggest encouraging module authors to implement Semantic Versioning or similar strategy; no need to include special flags, fields, etc. when version number itself clearly states if there's a (potential of) breaking change.

[adrian]

+1 for the idea.

For the implementation, I'd suggest encouraging module authors to implement Semantic Versioning or similar strategy; no need to include special flags, fields, etc. when version number itself clearly states if there's a (potential of) breaking change.

I am all for this idea, but I don't feel that the current system makes it easy. It seems that we are "encouraged" to use integers for our versions, but this doesn't really work when you run out of numbers. For example, how do I show version number: 1.2.11 ? I know Nico enters them exactly in that format with the periods, but I was following the pattern that Ryan and others were using with integers, so I just gave up on doing it semantically. Am I missing something?

[teppo]

On mobile so just a quick reply: strings work just as well. I've posted about this earlier, but IMHO whole integer version idea is flawed, exactly for the reasons you mentioned above. They can only represent a subset of version numbers. People also keep confusing them with octals, which is another issue..

[owzim]

+1 for the idea.

For the implementation, I'd suggest encouraging module authors to implement Semantic Versioning or similar strategy; no need to include special flags, fields, etc. when version number itself clearly states if there's a (potential of) breaking change.

K, so PW will check if the jump between the installed and the to be installed version is a major one, and then spit out a message.

I think a message/warning is necessary, because not everyone is familiar with the semver concept and does not automatically know what's up. This is more of an ux concern. Even a pretty tech savvy person like me want computers to assist me, I'd mess up all the time if there would not be warnings.

[Joss]

Me too!

I always say there are two reactions to hand holding - the wrong one and the right one:

Wrong - "Stupid machine! It finks I am stupid or something? I am not some stupid person that shouldn't be let near a 'puter! Stupid Newbs! And I fink Bill Gates is STUPID,  btw!"

Right - "I have got thousands of things to do and remember - I will take any help I can"

Guess who I like having round for tea?

(Satire comes free .....)

[Nico Knoll]

Maybe it would be enough to show a warning like "This module might not be compatible to it's previous version." if the version number changes from e.g. "1.6.4." to "2.x.x"?

[Joss]

"install or die!"

Sorry too direct?