If it helps, this is what I do in my extensions script.php file to check for the min requirement version:

public function preflight($type, $parent)
{
	$min_version = (string) $parent->get('manifest')->attributes()->version;
	$jversion = new JVersion;

	if (!$jversion->isCompatible($min_version))
	{
		$this->app->enqueueMessage(JText::sprintf('COM_SERMONSPEAKER_VERSION_UNSUPPORTED', $min_version), 'error');
		return false;
	}
}

@Bakual Yes, you can do anything in preflight, but why should you if Joomla should do this, and Joomla even got this in it's docs.

Since 3.6 you don't even need all that logic yourself in the scriptfile if you extend JInstallerScript, see the joomla.org template package scriptfile

Honestly, I always wondered why we kept that version attribute in the XML files since it hasn't worked since 1.6. With the new base scriptfile in 3.6, there's a part of me that wonders if we need to make it work again or if we can just update the docs to use the JInstallerScript integration going forward and remove the attribute from the core extension manifests and deprecate the documentation on that.

Actually I think if you're going to include this into 3.x, it will make a lot of extensions uninstallable and thus isn't B/C.
Currently, that version tag can contain anything as there are no checks in core.
In my extension I use it as a "minimum requirement" and check it in my script.php. Your code actually would break my installation on anything higher than the version currently set.
Also if 3.7.0 is released and extensions are having something like a 3.[56], then they will have to be adjusted to include 3.7 (if I understand your proposal right). That is imho not a good idea.

Since 3.6 you don't even need all that logic yourself in the scriptfile if you extend JInstallerScript, see the joomla.org template package scriptfile

Cool ?

@Bakual initially I've planned on it like check for "minimal version". But 'docs' would then be not right about [234], so I did it this way.

@mbabker , @Bakual
Not every extension need script.php, and forcing 1 extra file just for 'compatibility check' - seems to far overcoded.

@Bakual On B/C - latest move by JED is forcing developers to update their extensions .xml any way, so that's may be the right time to move a little bit farther.

What docs page are you talking about anyway? Since this has been broken since 1.6, I get the feeling that entire docs page references the 1.5 codebase only.

I believe we could use xml version just like minimal if some of maintainer would agree with that move instead of using docs.

On B/C - latest move by JED is forcing developers to update their extensions .xml any way, so that's may be the right time to move a little bit farther.

JED enforcing something so you can stay listed is one thing. Making existing extensions uninstallable without any reason is a completely different topic. Requiring developers to update the file for each new version is also ridiculous.
Also, as Michael said the minimum requirement is already taken care of in another way.

To be fair, I'm not against putting this (back) in. I'm just mostly questioning whether it's something that we need to do or if we can just leave it out and move on with using install scripts as the preferred way to do these things.

@Bakual My point is: extra files for such things aren't right.

@mbabker I believe there is sense in checking it with xml. Yes, may be as proposed, and not like in docs, check for minimal version instead of regex.

What docs page? I've looked through 5 or 6 so far and I can't find anything documenting that behavior at all (what a shocker).

Unfortunately I can't find this article right now, with exact text. Thought it was in my view not so long ago.
Articles that references minimal restriction approach trough xml file are:
https://docs.joomla.org/Manifest_files
https://docs.joomla.org/Creating_a_basic_templateDetails.xml_file

I honestly don't even know if this is the right spot but the only thing that it looks like the 1.5 code was in this block which was just a hardcoded "if version is less than 1.5" check.

So if it's going to be put back in, it probably shouldn't be regex based.

Yeah, the regex stuff is used in the updateserver XML files I think. But it certainly doesn't make sense in the manifest files. I always understood that one as a minimum version (which never worked).

Imho, the code in JInstallerScript is fine enough and it is fully B/C. If you want, you can add support for the version attribute into 4.0 (as a minimum version, not regex), but for 3.x I wouldn't do it due to possible B/C issues.

@Bakual what B/C breaks it can make with minimal check?

@mbabker Is someone having fun right there in repository without testing CI before?

Don't mind the AppVeyor thing. There's a pull request adding it for the repo and when I enabled the webhook it tried to run builds on some other commits it shouldn't have.

what B/C breaks it can make with minimal check?

Since the attribute currently isn't used, it can contain anything. It may or may not be compatible with your code. You just don't know it.

Same scenario if you add a new method or variable to a class. It may or not break existing uses in something else.

Not exactly. This isn't a new attribute. It's an existing one which wasn't used so far. It's not like it's just bad luck if someone used the same name like when we add new methods or properties.

It's at least something which has to be considered if we want to take risk. If it's deemed worth the risk, then I have no issues.

Find an extension using it against what either the 1.5 code did or the single manifest files docs page describes and maybe it can be called risky. Otherwise, I'm not seeing the problem here other than one of philosophy.

And yes, it is the same. If core adds a class var or method with same name and different function as another implementation using the same resources, it causes the same type of breakage or refactoring. So really to be "safe" you would have to analyze all extensions to determine what tags and attributes are all in use, how they're used, and decide on an approach that can absolutely not break any code out there now.

IMHO: that's not a B/C until developers did use "version" not as it supposed to [at least according to old docs] - minimal compatible version.
And if they did - well it's not B/C as they did something that they were not supposed to.

So I believe we (Joomla!) should make this easy check possible with xml file. No extra headache for developers, no extra semantic, no extra php files

@Bakual If you are not agree with statement above - look at #12834
There also was issue with developers might use something that Joomla isn't ready for now. Nobody called it B/C.

IMO this is a nice check and extension devs will like it. On the 3 series, I would just add the warning due the reason @Bakual pointed out. In J4 we can then abort the installation as made in this PR.

Meanwhile @mbabker I've just run into an issue that with one of my extensions. And it someway related to our conversation.
I've been updating JED listing and I understand that I should now check extension with JED checker and use updater to update old listing items.
So I went and tried to do this and guess what: the update site xml tag <targetplatform> is checked by the rule I was initially referring to: not minimal version, but version much 3.* or 3.[3456].
So I believe we should decide which to stick with in all aspects?
Just in case if anybody thought that I invented this matching rule...

And one off-topic clarification please as you're member.
JED Forces me to ensure my users see when my extension is up-to-date and alert them when update is available.
I've seen that Joomla provided how-to for resolving this process with akeeba and I believe @nikosdion .
BUT this way doesn't right to me and to some of our internal workflows, deployment strategy and so on.
I've already managed how-to do this right for me, and I'll share this scheme to world in future, but for now: one part of our deployment system is still not finished, we need some time, and it may be even 1 to 3 month.
I can temporary use Joomla Updater to inform my users about new versions, but not allow one click update (causing it to fail because of package would be not delivered) . This way: for some time [until internal scheme is finished] my users still will need to manually install updates, but they will see that there is an update in Joomla [Just like JED wants].
Question is: would this be treated as cheating? Or I can get some time to finish my work with this approach?

Personal opinion, I would leave the version attribute in the XML manifest to a simple number versus something that can be processed with a regex. If you really need something complex like that, as pointed out, it's already pretty easy to add this with the PHP install scripts. I don't think XML is the right place to do all this stuff but frankly I don't think the update system is well designed either so we're stuck with this arguably crappy XML parsing within the scope of the active Joomla install.

@mbabker Ok, I don't force anybody to regex version. My point is just not to forget that there is one more place with this issue.
And any thoughts on my second question?

Not a JED person so can't speak for them. I can say though I've seen other extensions do that so I don't think it's that big of a deal.

So I went and tried to do this and guess what: the update site xml tag is checked by the rule I was initially referring to: not minimal version, but version much 3.* or 3.[3456].
So I believe we should decide which to stick with in all aspects?
Just in case if anybody thought that I invented this matching rule...

Different use cases (and yes, I knew that worked there). Keep in mind that the updatesite manifest is always under your control. Which means if you found a bug after your extension release you can adjust the listing to show that incompatibility. If a new Joomla version is released, you can add that version to your targetplatforms.
On the other hand, the version tag within the extension manifest is out of your hand as soon as you released it. It will be downloaded and live on many harddisks all over the world. You should also not adjust anything in that release anymore. You can only release a new one with the adjusted version tag, but the old one is gone and can't be fixed.

The clarification offered by JED is that you are required to use the Joomla! update system to notify your users of the existence of an update, not necessarily for installing it. The idea being that there should be one and only one place where the user needs to go to see if their extensions are up to date.

That said, not being able to update the extension through Joomla is a nuisance to the user and possibly confusing. I'd recommend that your update XML file includes an update download URL which results in an HTTP 403 error page with short text content to the tune of Updates through Joomla extensions update system are not yet possible. For instructions on updating FOO BAR EXTENSION please refer to http://www.example.com/how_to_update.html The HTTP status text is displayed by Joomla and could probably help your users figure out what is going on when the update fails.

DISCLAIMER: I am NOT a member of the JED and I cannot speak on their behalf. The information above is correct to the best of my knowledge. I think @anibalsanchez would be a better fit to reply here.

@Bakual I got your point, but:
If there any issues with version tag - xml file wouldn't live on hard disks, but will disappear in trash;
If everything is okay - everything is okay )

Okay @nikosdion , thanks! As far as I remember there was just error message without translating response when I tried this before[few month ago]. Thanks again.

If there any issues with version tag - xml file wouldn't live on hard disks, but will disappear in trash;

I may download (even buy) your extension and store it locally to use on various sites. I was able to install it on a few sites.
Now a half year later Joomla was updated to the next minor release and everything still works fine. But when I try to install the same zip on a new site, it will not allow me to install it. If it's a paid extension I would have to pay again to get an updated one that is installable. There doesn't even have to be a bugfix in it, just a changed version attribute.
And now what happens if the extension isn't supported anymore? You just can't install it anymore.

That's why I think it's not a good idea.

@Bakual I believe you lost track of what's going on right here. Nobody talks about staying with RegEx strict version already. Even code is changed at least a day before.

I thought you believed 3.[3456] is a good idea. If not, then all is fine and I shut up ?

@nikosdion You are right. At this time, JED accepts extensions that only inform users about the available updates and display a message saying that the update is available.

For instance, some developers prefer to deliver updates manually or via mail.

For more information, Joomla! Update System requirement

@alex7r can you give please clear instructions how to test?

Try to install extension with version 3.7 in version tag. Message should appear that extension might be incompatible.
Try to install extension with version 3.0 in version tag. No message should appear.

can you give an Example of an 3.7 and 3.0 Extension to test?

Sorry for BIG delay.
https://github.com/alex7r/extendedmeta/archive/staging.zip starting from 3.1
https://github.com/alex7r/extendedmeta/archive/alex7r-test-3.7.zip starting from 3.7

Revisiting this, at this point I would suggest the attribute be deprecated and removed (it's not like core is using it so a simple PR just removing it from core extension manifests is enough). This type of compatibility checking should be performed through a preflight script, especially as the PHP hook will allow the extension to check and warn on other potentially missing dependencies (such as the minimum supported PHP version being higher than your current version or required PHP extensions).