[UserStory] Development jar should be named QualityTools-[version].jar

[jody]

User Story

Essential components

• Title describes the story
• Stakeholder type is identified
• Outcome is described
• Rationale is explicit
• Acceptance criteria are verifiable and from the perspective of the stakeholder

Story

As a maintainer
I want the name of jar files used for testing to be "QualityTools" followed by the current version
so that I have a consistent way to identify the build associated with the jar file.

Acceptance Criteria

• The names of non-production jar files, such as those used for testing and validation, include the version of the product (as defined by the development conventions).
  For example, if the product version is 2019.11.21, then the test jar file is named QualityTools-2019-11-21.jar

• Constraint: a non-production jar file name must not include more than one period "."; for example, the name QualityTools.2019.11.21.jar is unacceptable.

Related Information

Naming production jar files: #138

[jody]

The Development Conventions lacks specification of how versions are identified. Needs new User Story defining version strings.

[shadycloud]

Ok, so maybe I didn't know what I was talking about in #138 *** I found something about that today, "Usually, you should avoid putting a version into the source files. Ideally, you would have a build process that encodes the version into the build number. That way the version is independent of the source used to build it with. That process can then also encode the commit id somewhere, so you always know what source is was built from. And as for storing the version number, the common solution for that is using tags. This also gives you the benefit that you can easily browse by version in your repository by looking at the tags. – poke Jun 17 '16 at 6:35" -https://stackoverflow.com/questions/37814286/how-to-manage-the-version-number-in-git

[shadycloud]

Found a helpful resource in regard to semantic versioning tonight, https://semver.org/
Also mentioned on pg. 54 of ProGit, S. Chacon and B. Straub, Pro Git, 2nd ed. Mountain View, CA: Creative Commons, 2019. [Online] Available: https://git-scm.com/book/en/v2

[jody]

Found a helpful resource in regard to semantic versioning tonight, https://semver.org/
Also mentioned on pg. 54 of ProGit, S. Chacon and B. Straub, Pro Git, 2nd ed. Mountain View, CA: Creative Commons, 2019. [Online] Available: https://git-scm.com/book/en/v2

It was also in the Fall 2019 CS3250 Moodle course: Semantic Versioning 2.0.0