MCP-0016: Semantic Versions for Libraries #1728
Comments
|
Modified by dietmarw on 9 Jun 2015 14:51 UTC |
|
Comment by mwetter on 10 Jun 2015 17:19 UTC As not all library developers may be aware of what a backward compatible change is, and because it may quickly happen that a non-backward compatible change gets on the development branch inadvertently, I think robustness of library versioning could be increased if developers had access to a script, or at the minimum a checklist, that can be used to verify whether a library is indeed backwards compatible. A (likely still incomplete test) could be that
As I doubt that all library developers will use semantic versioning, a keyword would be useful that indicates that a library indeed uses semantic versioning. I suggest a library should opt-in to use semantic versioning. |
|
Comment by hansolsson on 24 Jun 2015 08:32 UTC
I also tried to investigate how to best do this (i.e. planning to actually implement the feature), and then I got stuck since I realized that we haven't clearly defined what is allowed in various versions - and it is not even clear that it is possible (see below). (I tried to look through the documents for this MCP and couldn't find anything.)
These restrictions on minor version are similar to "plug compatibility" (in section 6.4 of the specification) - which is basically to say that a user could redeclare a component of the old class with the new one. (Additionally you require that the same value shall be used; that is problematic to check - and additionally I assume some want to allow minor tweaks of values.) Similarly the restriction on patch-releases can be compared to the restriction in MSL for updates of the maintenance branch. (Alternatively that you can redeclare in either direction.) However, the restrictions on the maintenance-branch in MSL are not 100% safe. And with current Modelica I don't see how we can have 100% safe restrictions on non-major releases that allow current development. The changes in Modelica Specification to allow 100% safe realistic changes in libraries seems major (with realistic I mean usual minor changes for current modeling-building paradigms), and I am not certain of the exact details - or even if it is possible. However, the unsafe cases are (a bit) farfetched, and we could accept that some things may break in rare cases - similarly as the restrictions on the maintenance branch of MSL (and of course a bug-fix can also break the behavior of some user models). Note that I'm not saying that this makes it impossible to have semantic versioning in any form in Modelica, only that we need to define it clearly - and have realistic goals. A minimum goal would be to use semantic version numbers without the semantics of semantic versions would be a solution, but it hardly feels like progress. |
|
Comment by sjoelund.se on 24 Jun 2015 08:44 UTC
A development branch is not the same thing as a release. It is possible to use pre-release version numbers on the development branch. |
|
Comment by hansolsson on 24 Jun 2015 09:14 UTC
I would more strongly say that one should use a pre-release version on the development branch (as soon there is any development). However, that doesn't solve M. Wetter's problem, since it depends on what pre-release is it! |
|
Comment by sjoelund.se on 24 Jun 2015 09:20 UTC
Not according to semantic versioning:
It is probably a good thing if pre-releases do satisfy these requirements, but they do not need to. |
|
Comment by hansolsson on 24 Jun 2015 09:38 UTC
Are you sure? The semantic version specification both state that the minor version number MUST be incremented for any new functionality (without any exception for pre-release versions), and that pre-release versions MAY be indicated with additional information and it might be unstable and not satisfy the requirements on released versions. Only the requirement for minor version is a "MUST" which is clearly defined. My interpretation is that pre-release versions ideally should satisfy the requirements, but since they are not fully tested it is less guaranteed than for released versions. (Even released versions may break compatibility by mistake, that is covered in the semver-faq.) Added: However, the main point from M.Wetter is how to avoid releasing this breaking change by mistake; and for that case I say that not adding the changes at all seems the safest choice. (Which can then be combined by verifying it afterwards.) |
|
Comment by sjoelund.se on 24 Jun 2015 09:46 UTC |
|
Comment by hansolsson on 24 Jun 2015 12:00 UTC
And still the spec states that you MUST increment the version number, not merely that you should do it. A simple conclusion is that SemVer spec is inconsistent, which has been reported by others (primarily regarding released versions that were incorrect): Which contains the following about violating the "MUST" for incrementing versions:
See also semver/semver#124 Added: However, regardless of this we are in agreement that the pre-release versions SHOULD NOT contain incompatibilities that would be incorrect for the corresponding released version. The term 'SHOULD NOT' (using RFC 2119 as in SemVer) is a recommendation where exception can occur - and "user made an error that will be corrected" would be a valid exception in my opinion - but still something that we should try to avoid. |
|
Modified by dietmarw on 18 Sep 2015 07:56 UTC |
|
Comment by henrikt on 23 Sep 2015 10:37 UTC Before going to the problems, however, I'll state some things that seem clear to me at this point.
Main problems
When library version 5.0.0 is released, backward incompatible changes can hopefully be addressed with conversion scripts, so from(version={"4"}, ...) is added, and the conversions then remain unchanged until library version 6.0.0 is released. The difficult part is how to handle conversions for libraries that started out using non-semantic version numbers. For the sake of discussion, consider a variant of conversion annotations that specify both a source and target version, and let's say that version 4.0.0 of the library was the first version using semantic version numbering: Since the library is now using semantic version numbering, no new conversions will be needed when releasing 4.0.1, 4.1.0, 4.1.1, 4.2.0, etc. Not until version 5.0.0 is released does it make sense to add a new conversion: Now, the problem is that library version 5.0.0 being marked with language version 3.S or later does not say anything about which language version that was used for library version 4.Y.Z. Consider trying to find a conversion for a model currently using library version 4.3.2:
Since the library is using semantic version numbers as of version 4, it should be safe to use "4" as an abbreviation of "4.0.0" to remove redundant zeros and to make it harder to make the mistake of specifying illegal conversions: Yet another question related to conversion annotations is how to make a difference between major versions where a conversion is able to take care of upgrading models, and major versions where no such conversion exists. Making a difference may not be strictly necessary, but it would tighten the integration of semantic version numbering and conversion annotations, see the section on having a generation number as part of the version below.
|
|
Comment by henrikt on 24 Sep 2015 14:27 UTC
|
|
Comment by hansolsson on 25 Sep 2015 08:36 UTC There are three parts of semantic versioning:
Versions number in Modelica 3.3r1 are defined including ordering (except as listed below). The version numbers in Modelica 3.3r1 are more general (more levels) - and are slightly different than semantic versioning - using space instead of hyphen to separate pre-release/beta versions, and having "build" as a separate number instead of part of the version number. The comparisons of versions use the same logic in Modelica 3.3r1 and semantic versioning; except for some odd cases for hierarchical pre-release versions (which I don't think we have used; basically SemVer allows "Beta.9", "Beta.10" to be correctly ordered). There are also unordered versions in Modelica 3.3r1 - that was intended for things like "MyVersion", "Testing" - I don't know if anyone actually uses those version numbers; and I don't have any strong feelings about them. But what abut semantics? Modelica 3.3r1 does not define any semantics for the versions, and I believe this should be main focus - but there are three main issues:
This means that we need to completely need to define the semantics of versions and cannot just reference an existing version of Semantic Versioning. The things we need to consider are:
One might think that we could define the public API in a way that does not allow "extends ..." from non-partial classes. However, e.g. VehicleInterfaces have non-partial classes that are intended to extend from - with no special marking; and there are also other cases where extending is normal. If we cannot find a 100% safe solution the benefits seems less clear. One possibility would be that we could e.g. extend the uses-annotation to indicate that we use more than the public API, e.g.: "uses(Modelica="3.2", extendingFrom= true)", but how and what it brings isn't clear. I'm not saying that using the semantics of semantic versioning is a bad idea or impossible - just that the details are unclear at the moment; and we have a lot of work to do - and that success is not guaranteed. Replying to [comment:11 henrikt]:
I am not sure that we can make an informed decision whether semantic versioning should be required starting from a specific version or not before we have more information about the details - as indicated previously 'public API' is not clear. Thus I would propose to delay this until the other issues are resolved, or possibly having it optional while we are working on the details - that would allow us to get some of the benefits before everything is clear.
I agree that we need to handle cases where errors have occurred in a good way, and will later try to explain how that could be handled. I am not even sure that the SemVer specification allows you to say that only some library versions are semantically versioned - i.e. even if we don't make any mistakes in the future we might still not be able to say that MSL is semantically versioned due to older versions. You might argue that this is extreme - but either we follow an existing version of SemVer (which doesn't work in case of errors) - or we clearly define our own rules "in the spirit of SemVer".
Having four part version numbers is also an alternative that can be discussed, and is close to the current MSL versions, except that Z is separated out into the build-number. (A separate build-number has some minor problems, e.g. pre-release versions of builds are oddly numbered: "3.2.1 Release Candidate 5" - build 4 is more logically "3.2.1.4 Release Candidate 5" in the sense that the Release Candidates are per build.) I understand that for other projects this is also quite common, and have seen several people arguing for adding something like that to Semantic Versioning. However, it is not any version of Semantic Versioning 2.0.0. But if we anyway have to define our own rules that is not a problem - we just need clear understandable rules. |
|
Comment by choeger on 25 Sep 2015 09:40 UTC
My pragmatic conclusion would be to introduce mandatory semantic versioning syntax, semantic versioning ordering semantics and, optionally, semantic versioning compatibility semantics (e.g. by an additional annotation). That way, a library could safely migrate to complete semantic versioning semantics by setting a flag and still use semantic versioning syntax for older versions. |
|
Comment by henrikt on 25 Sep 2015 10:00 UTC To me, there appears to be several important subtopics of this discussion, with the most difficult one being how to define backward compatibility in a useful manner. I don't see how we can manage discussion of all of these topics at the same time in this ticket alone. How about creating sub-tickets for the different sub-topics, so that each can be discussed in isolation? |
|
Comment by henrikt on 25 Sep 2015 10:16 UTC
There was lengthy discussions about this in Waterloo, and then, the conclusion was that semantic versioning should be mandatory as of the language version where it is introduced. This causes no problems for legacy libraries, as they will still use an older version of the language, and when a new library is released using the new version of the language, one just have to make sure to bump the major version if the previous version number was in the form of a semantic version number. The more general argument for making semantic versioning mandatory is that we don't want a language with features that can be turned on and off. If we introduce an optional language feature now, this would be an excuse for introducing even more feature switches when it is hard to find agreement on other language improvements in the future. For example, I sometimes find it a bit scary that there are non-differentiable built in functions that don't generate events, but I understand that introducing a feature switch for this into a growing collection of switches would be a mess both for users and tool makers. |
|
Comment by hansolsson on 30 Sep 2015 13:12 UTC The different version schemes mostly differ in how they construct ONE string containing all parts of the version-information (API-version (possibly split into (generation), major, minor), patch (or build), pre-release-information, meta-data). Having one string is useful for tools - but for humans it seems easier to understand if we actually present the parts separately. This has also been both for the Modelica Standard Library and Modelica Language Specification. Considering some recent MSL and MLS version we have: MSL 3.2.1+build.4-rc1 -> MLS 3.3 revision 1 -> MLS 3.4 -> There are then two separate questions:
As for the currently unnamed version a simple idea would be to just use the date, e.g.: "2015-09-30" (i.e. YYYY-MM-DD format); since they will be sorted correctly and before any alpha/beta/rc. (It is formally a valid pre-release identifier in semantic versioning, even though not exactly in the spirit.) It might also be that we need something completely different during development (i.e. before the beta-phase). Replying to [comment:14 choeger]:
I agree that an ordering is needed. And just to be clear: the current Modelica Specification already provides a partial ordering for versions (which for normal versions is the same order as defined by semantic versioning).
To me there are two parts of the compatibility semantics: patches and normal versions. I believe the specification could limit patches to compatible bug-fixes (that distinction is fairly clear), but the separation of other changes into minor/major is currently semantically unclear and should be optional. |
|
Comment by otter on 12 Nov 2015 10:04 UTC
Does this also work if there are different forks and different branches in different forks? Even if this works then this means probably that for every committ "somehow" the version number has to be updated in the library (which seems not practical). |
|
Comment by hansolsson on 12 Nov 2015 10:23 UTC
If you rely on the git-hash to disambiguate versions you are not following semantic versioning (depending on version that is either a bit wrong - or completely wrong). As I understand your scenario with distributed development scenario it might be that 405, 413 and 473 is one branch and 406, 413 (with other hash) and 460 are on another branch. An issue with distributed development is that there is no strict order between the versions on different branches that make sense (as assumed by semantic versioning), but what you state is that users only look at a sub-set of version (the nightly builds) - and that sub-set is strictly ordered (since the nightly builds are centralized). Basically you are not really following any published version of semantic versioning - but something inspired by it. That wouldn't be a problem if people stated that (and specified those rules). Added: Mathematically speaking the difference is that semantic versioning imposes a 'total order', but we only have 'partially ordered set' (at least for the distributed development versions). |
|
Comment by sjoelund.se on 12 Nov 2015 10:47 UTC
We don't. The released versions will all use unique identifiers though (which are monotonous). A git describe in someone else's repository might use the same id, but the official repository's HEAD will not re-use IDs. With the hashes, you can tell if someone for example uses a different repository or branch (so, unofficial releases). No one else can make an official release anyway. I mean... some random person (let's say me) can't start distributing MSL as 4.7.3 and expect that it follows semver. And the fact that someone would create this file does not magically make the official MSL not follow semver anymore. Of the releases (made from the HEAD of the master branch on the development server), the ordering is total. And that can be considered authoritative. Note: Maintenance branches can be handled in a similar way (if for example, the last release is 3.3.0, you can have it auto-increment release builds like 3.3.1 for 1 commit into the branch). Anyway, I do not think it is problematic as long as one sets up a good system for how to deal with versions. |
|
Comment by hansolsson on 12 Nov 2015 11:20 UTC
I agree, and the problem is that we need a good system for how to deal with versions, or more specifically:
|
|
Comment by choeger on 12 Nov 2015 13:18 UTC
Why? In what scenario would there be which problem? e.g. the linux kernel follows something very similar to semver and is one of the largest distributed projects that I know of - so I assume they would have hit any practical problem. |
|
Comment by hansolsson on 12 Nov 2015 14:10 UTC
The Linux kernel uses a hierarchical numbered version number for released versions; I believe we all agree that it makes sense - and we already use that for MSL, and it is specified in the current Modelica specification. However, Linux kernel does not follow semantic versioning (in terms of version numbering and semantics). Even the current Modelica version specification seems closer to semantic versioning than the Linux kernel versioning described below. At least according to For the semantics the Linux kernel is not following semantic versioning (regarding API-changes). That's why Linus asked if he should make Linux kernel 4.0 or not; whereas it for semantic versioning would be automatic iff any internal API in the kernel had any incompatible change. I have a feeling that telling Linus to use semantic versioning in its current form might not get a polite response. |
|
Comment by henrikt on 13 Nov 2015 08:21 UTC
I'll try repeat/rephrase what I think sjoelund.se already explained here. The good intention to have distributed development in mind does not mean we should promote versioning anarchy by the way we open things up in the semantic versioning scheme we decide on. Distributed development is good, but having multiple authorities that independently define their own official version numbers for the same library is not good. Each library should have one authority that defines the content of official releases that the corresponding version numbers. In my opinion, a contributor should never introduce version numbers deriving from not yet officially released version numbers. If the intention is to make a new feature part of a specific not yet released version, there are cleaner ways to communicate this to the primary maintainer than to encode it in a semantic version number. For a big contribution project, clearly communicating which (feature) branch is being distributed is probably a better idea than fiddling with the semantical parts of a semantic version number. Users will have to be aware anyway that they are not using an official release, and a version number like 4.3.2+NewMultiBody.7654.gea54626 could be one way of telling that this is a non-official release of the NewMultiBody project, currently 7654 commits from the official release 4.3.2, having hash gea54626. (Note that it is the NewMultiBody project itself that decides to include its name in the build metadata.) Since not everybody is using Git, we cannot decide on a semantic versioning scheme where a Git hash is a mandatory part. We just have to make sure that the scheme is flexible enough to make it possible to specify build metadata like the one used by OpenModelica or in the NewMultiBody example above. |
|
Comment by hansolsson on 13 Nov 2015 09:21 UTC
I agree, and my main input is that distributed development and sites like github makes it even more important to have a good versioning system, because the development no longer have a strict order(the official releases still do), and all versions are available to the public at the same level (including development ones).
Yes, something like the above might work. One solution might be to be generous with project names (and use user-names as backup/part of hierarchy) - and/or possibly accept that development versions may not unique version numbers. An interesting part of this is that you are also discussing post-release development, i.e. 4.3.2+changes whereas semver only discusses pre-releases 4.3.3-notYetDone. (There are several proposals for changing this aspect of semver, of course.) If we consider a distributed scenario where people want to (report and) fix bugs and propose additions I agree that the scenario of post-release version might in many cases be a preferable alternative to pre-release versions. |
|
Comment by henrikt on 13 Nov 2015 09:45 UTC
Right, let us not try to enforce global uniqueness of build metadata. We would be doomed to fail unless we introduce something the size of reverse DNS namespaces for build metadata. Imagine having to deal with version numbers like 4.3.2+com.wolfram.NewMultiBody.7654.gea54626, and how projects would have to agree on which reverse DNS to use… and not even this would work for individual contributors that don't have their own domain… I don't think that we shouldn't even define project and/or user names in the versioning scheme, only not that such things should go into the build metadata part if someone wants to include such information. We should not define semantics for the build metadata, so by just looking at a semantic version number with build metadata, it won't be clear if the alphanumeric chunks denote project names, user names, branch names, exceptional hashes, or whatever. The interpretation of the build metadata should be defined where the non-official version is being distributed. Let us focus on the semantics of official release versions, including official pre-release versions. |
|
Comment by mtiller on 13 Nov 2015 13:29 UTC
I'd like to address the two comments that "Semantic versioning (in current forms) does not fit the requirements of distributed development" and "distributed development and sites like github makes it even more important to have a good versioning system". Let's take a step back here to recognize that That being said, one advantage they have in the Javascript world is the de facto universal registry that is npmjs.org. So in some sense, what we might be missing is a definite source for naming that disambiguates any competing claims to a name. But that is part of what Dietmar and I have been trying to do with the impact project because if you look carefully you will see that the public impact index (which is what is used by our impact search engine(impact.github.io) and the In summary, GitHub+Semantic Versioning = proven success at scale. I would argue that what this discussion highlights more than anything is the need for a universal registry of Modelica packages and an associated index. That is what we are trying to do with |
|
Comment by hansolsson on 13 Nov 2015 13:45 UTC
I agree - except a terminology change. We shouldn't call it metadata as that causes confusion with metadata in semver (which is ignored for the versioning - more or less strictly depending on version); whereas this development-tag is an important part of the version. What I don't want is to that claim that we use semver - and/or its terminology and then have different semantic meaning, even if we certainly wouldn't be the first ones to do that.
I agree that the important part is handling official versions, and being able to tell if it is an official version or not. |
|
Comment by henrikt on 16 Nov 2015 07:43 UTC
OK, but then we don't agree. :) What I suggested was to use the semver metadata concept, so that we don't have to define order in version number anarchy (where anybody is entitled to introduce version numbers at will, and distribute more or less official versions of a library in a completely decentralized manner). The official registry that Mike suggested in comment 37 would be one way of defining what the official version numbers are, as well as indirectly defining the authorities defining version numbers for each library (by means of privileges to add new version numbers to the distribution site listed in the official registry). Personally, I think that each library would be able to define this by itself, without a need for an official registry. If a library fails to include a README file listing the primary distribution site and/or include this information in the top level package documentation, they might as well fail to register themselves with the official registry. (In my opinion, an official registry plays a more important roll for the allocation of library package roots — compare Java namespaces.) Anyway, I think the main point that Mike is making here is that the important thing is defining what the official versions are, rather than trying to define semantics of non-official versions.
Sure, that seems sensible. It's just that, at the moment, the terminology from semver is still the best match for our discussions. In the end, we will need to define our own terminology, but even then, I think that large overlap with semver terminology is desirable to avoid confusion when talking about versions with those who have already adopted semver terminology for their mental picture of semantic versioning in general.
Again, this is not something that has to be clear from the semantic version number itself. It is enough to assume that each library has a single official site where official versions are defined. If a version is listed there, it is official, and vice versa. If you want an official release of a library, don't use a version with build metadata in the version number; get yourself a plain version instead, and it will be an official version as long as there aren't wild contributors to the library out there that don't respect the library's build metadata scheme (which should, at least, ensure that any deviation from an official release is marked with some sort of non-empty build metadata in the version number). Again, if we focus on the semantics of official releases, it should be up to each library to define how to use the build metadata part of the version number. |
|
Comment by hansolsson on 17 Nov 2015 15:40 UTC
I see, the idea is that we follow semver syntax and official versions have special "metadata" tags (either empty or some "magic" mark - which may depend on the package); and non-official versions have different non-empty ones. That is fine and could work if we describe it.( * ) However, using the meta-data to give precedence to different versions is not semver 2.0.0 semantics from http://semver.org/ (and later even clearer): Using pre-release syntax would require more discipline (as previously indicated) - and one can view this as reinterpreting meta data as "post-release information" ("-" means before and "+" after!). *: One possibility would be cryptographic checksum for the official releases, although there are issues to resolve regarding that. Replying to [comment:37 mtiller]:
The claim is that there are 205,000 packages and they state that they use semver. Well, when I looked of the most recently changes packages 7 of 12, and for the most downloaded 6 of the 20 were below version 1. That means that semver does not give ANY compatibility guarantees for those packages. And for the ">=1.0.0" packages when looking I could see that many don't *strictly* follow semver (looking through changelog), and semver makes it clear that you can only follow it strictly; once your package is no longer semver compliant you are out. I believe that strictness is what attracts many to semver (it sounds impressive) - but then the strictness is often ignored in practice (when it comes in conflict with practical problems). Additionally even npmjs does not strictly follow semver, in particular the precedence is different regarding pre-release tags (I actually find that the npmjs-precedence makes more sense than the semver one and solves some problems, but it doesn't suffice). So, the point remains that forking in git and github causes similar problems for both semver and the Modelica License; and I don't see why we should solve one and ignore the other. |
|
Comment by mtiller on 17 Nov 2015 16:32 UTC Furthermore, people who label their code with incorrect versions are irrelevant. No matter what system we come up with here, users will always be free to abuse the system. The important point with It would be more helpful if you pointed out specifically what you mean when you say "npm" doesn't follow semver for pre-releases. It may very well be true, but I couldn't find any reference to what you are talking about. Finally, what would be more compelling as an argument would be to point out where any of these issues actually impacted somebody. We spend a lot of time in Modelica chasing ghosts of problems where actual problems don't exist. My point was that lots of people use npm successfully. Nothing you said refutes that statement. This discussions is, in my opinion, a great example of the proverb "Perfect is the enemy of good". What is to be gained by spending what is likely to be years arguing about the perfect versioning system? I am willing to stipulate that semver may not be perfect. But I assert it is good enough and I don't feel you've demonstrated otherwise. |
|
Comment by hansolsson on 17 Nov 2015 17:39 UTC
And 6 out of 20 most downloaded packages were such packages.
If a specification has an 'absolute requirement' it is not irrelevant if people break it. According to semver the package is no longer compliant. The specification text for semver (in contrast to the FAQ) does not specify ANY way of getting back on track - or what 'back on track is', in fact there is NO WAY back. That does not help users; so people ignore that and try to be sensible instead.
https://docs.npmjs.com/misc/semver#prerelease-tags
The problem exists if we actually follow semver, but since you seem unconvinced that an absolute requirements matter - let us consider a practical example: I agree with the change, and I don't like that people are afraid to make sensible changes - just because of some theoretical compatibility issue. Users don't complain if the interface is incompatible with previous version; they only complain if the change impacted them negatively.
I don't want a perfect a versioning system - just one that has rules you can actually follow; whereas semver claims to be the perfect system. And I didn't say that npm was bad - I discussed problems with semver, that matters since npm handles semver syntax and semantics that are both semver and semver-like. So, I don't want a perfect versioning system just something basic with a suitable syntax and some rules (similar to the npm-summary of semver):
The "normal Modelica models" needs to be defined to make it suited for Modelica; see comment 2 and 3 above - it is amazing how little the concrete problems of defining compatibility in Modelica have been discussed. |
|
Comment by henrikt on 27 Nov 2015 08:49 UTC |
|
Modified by dietmarw on 2 Dec 2015 10:08 UTC |
modelica-trac-importer
added
MCP
|
Comment by hansolsson on 13 Sep 2016 13:16 UTC One possibility is to split off separate tickets for specific topics - and just cross-linking them to this one. Do we agree that this is a good idea? Yes. Some trac-systems can create sub-tickets, dependencies etc - we will just have to handle that manually. E.g. we will have to ensure that all subtickets are closed before closing the main one. We could also install the addon in trac for it - but then it adds maintenance. |
|
Comment by leo.gall on 24 Apr 2018 11:56 UTC How do we get going, again? Plan a joint meeting of MAP-LANG and MAP-LIB? |
|
Comment by dietmarw on 24 Apr 2018 12:20 UTC So the pragmatic solution is to simply use this as also suggested by @HansOlsson |
|
Comment by henrikt on 26 Apr 2018 20:23 UTC I still think it will be necessary to break down the discussion into sub-topics, before organizing something as big as a joint MAP-LANG and MAP-LIB meeting. Perhaps someone from MAP-LIB would like to join the working group, and then the working group could begin by doing the break-down? With a better overview, I hope we (as in this ticket thread) will be able to identify the most important sub-topics to be discussed in a bigger group. |
|
See also #3209 for the specific issue of what "backwards compatible" actually means. |
Modified by dietmarw on 2 Dec 2015 10:08 UTC
We identified several potential “levels” of semantics. The first level was the idea that all libraries must use semantic versions syntax. This would have the basic benefit that it would address issues about how to express things like pre-release versions. It also provides a basis for defining ordering as well.
This MCP is about how to deal with semantics of version numbers. By this we
mean conclusions that could be drawn about compatibility between different
versions (e.g., something that uses 3.2.1 should be able to use 3.2.2). One of the topics that come up was the idea of bugs and bug fixes. It might be that API compatibility may be present, but that the actual implementations have issues.
Based on this, it was felt that the uses annotation was still useful because it allows a level of explicit dependencies. For this reason it was felt that library developers should be able to utilize semantic version compatibility but also to explicitly override it.
Document location
Current members of the working group
Modified by dietmarw on 18 Sep 2015 07:56 UTC
We identified several potential “levels” of semantics. The first level was the idea that all libraries must use semantic versions syntax. This would have the basic benefit that it would address issues about how to express things like pre-release versions. It also provides a basis for defining ordering as well.
This MCP is about how to deal with semantics of version numbers. By this we
mean conclusions that could be drawn about compatibility between different
versions (e.g., something that uses 3.2.1 should be able to use 3.2.2). One of the topics that come up was the idea of bugs and bug fixes. It might be that API compatibility may be present, but that the actual implementations have issues.
Based on this, it was felt that the uses annotation was still useful because it allows a level of explicit dependencies. For this reason it was felt that library developers should be able to utilize semantic version compatibility but also to explicitly override it.
Document location
Current members of the working group
Reported by mtiller on 9 Jun 2015 14:35 UTC
We identified several potential “levels” of semantics. The first level was the idea that all libraries must use semantic versions syntax. This would have the basic benefit that it would address issues about how to express things like pre-release versions. It also provides a basis for defining ordering as well.
This MCP is about how to deal with semantics of version numbers. By this we
mean conclusions that could be drawn about compatibility between different
versions (e.g., something that uses 3.2.1 should be able to use 3.2.2). One of the topics that come up was the idea of bugs and bug fixes. It might be that API compatibility may be present, but that the actual implementations have issues.
Based on this, it was felt that the uses annotation was still useful because it allows a level of explicit dependencies. For this reason it was felt that library developers should be able to utilize semantic version compatibility but also to explicitly override it.
Document location
Migrated-From: https://trac.modelica.org/Modelica/ticket/1728
The text was updated successfully, but these errors were encountered: