mirror of
https://github.com/semver/semver.git
synced 2026-03-09 23:42:06 -05:00
Define "package" #127
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#127
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ecki on GitHub (Mar 27, 2014).
In the Java and OSGi world "package" is a term with a specific meaning. (And especially in OSGi you could even have a version number on seperate packages inside a bundle). I would therefore recommend you define that with package you actually mean "deliverable" or "deploymet unit" and not "java package". Or you define that the granularity at which you apply the version number might be on "API", "(osgi) package", "packages", "operation" or "deployment unit" or "application" level.
@crazedsanity commented on GitHub (Mar 27, 2014):
Can you give a better explanation of where the versions generally live in a Java deliverable? It would be useful to explain in a way that does not require in-depth, Java-specific knowledge.
@ecki commented on GitHub (Mar 30, 2014):
Sure I can, but I guess it is not really in scope for the semver (main) document. Java has no notion of versions of classes (other than the binary compatibility version of class files). In a Java Archive (JAR) you can have a manifest, and there it is possible to specify a implementation version. This is mostly informative, but can be queried on a Java package level.
If you go to OSGi those Java Archives have the role of a OSGi bundle. They can have a explicite Bundle-Version in the Manifest. This version can be used declarative and descriptive. But typically dependencies are done by requiring or exporting java packages with a OSGi version attribute (also in the Manifest).
My bug report is simply about the fact, that the semver main document does not define what it means with package (and in the java or OSGi world it can mean something entirely unrelated).
@crazedsanity commented on GitHub (Mar 31, 2014):
A "deliverable" might have a specific meaning in some other context just as "package" does for Java. It seems like obfuscating the wording for the sake of being language-agnostic would be counterproductive. I'd be interested to hear other's thoughts on it, though, as I am far from an authority when it comes to this repository/document.
@ecki commented on GitHub (Apr 1, 2014):
@crazedsanity yeah I somewhat agree, might be a too big task to find the better word. However the title of the bug still holds, the term "package" used without any definition is a problem. And I am willing to contribute a formulation for a definition (once I am sure what the actual meaning is).
I would think that "deliverable" or "artifact" would be a good alternative in situations where actually an API/implementation is defined in terms of those products. But it might not cover situations with a unusual lifecylce.
@bartlettroscoe commented on GitHub (Dec 7, 2014):
A "Package" should follow the rules of Packaging Principles. One key principle of course is "Reuse-release equivalence principle (REP)" but there are other that should be considered as well.
We are trying to work on a maturity model that addresses backward compatibility that defines when applying strict "Semantic Versioining" is appropriate. In particular, late stage "Production Growth" and "Production Maintenance" is where one would apply strict "Semantic Versioning". See The TriBITS Lifecycle Model.
@ecki commented on GitHub (Dec 8, 2014):
So the question is somewhat unanswered: what does semver mean when it speaks of package? is it more a deployment unit, a project or a language construct?
@jwdonahue commented on GitHub (Dec 6, 2017):
@ecki, I have always assumed that when a specification does not provide its own definition of a word, the "standard dictionary" for the language the spec is written in, provides the definition. In this case try looking at http://www.dictionary.com/browse/package?s=t and assume the SemVer spec intended a liberal application of those definitions, or to quote @mojombo's own words from the introduction:
Unless you have further questions or wish to issue a PR, please close this issue at your earliest possible convenience.
@ecki commented on GitHub (Dec 6, 2017):
the dictionary link does not help when one(?) for programming language where the spec is applied its a different terminology. But I open a request with what I understand. The FAQ format is better than trying to shoehorn it into the formal definition. It is just a good thing to acknowledge that not all eco systems understand package as an term deployment unit. (And deployment unit might not always be the unit of versioning, think Web API or with modules)
@jwdonahue commented on GitHub (Dec 6, 2017):
Now that's a really good start! I think you should issue a PR to semver/semver.
@Haacked (FYI).
@jwdonahue commented on GitHub (Oct 8, 2018):
@ecki , if you intend to carry this forward, you need to issue PR here on semver/semver. Otherwise, please close this issue at your earliest possible convenience.
@ecki commented on GitHub (Oct 17, 2018):
Looks like I am the only one struggling with the definition.