search

tea-lang-org / tea-lang

DSL for experimental design and statistical analysis
Apache License 2.0
253 stars 32 forks source link

[Proposal] Versioning of the package #50

Open MaLiN2223 opened 4 years ago

MaLiN2223 commented 4 years ago

How should we version the package? I have noticed that we are currently at 0.2 but this has not changed for a while.

Modyfiying the version number makes it easier to find bugs and helps with updating the package.

If there is no preference, I would like to propose the pattern similar to the one proposed by Microsoft Major.Minor.Patch[-Suffix]

From the linked website:

Major: Breaking changes Minor: New features, but backwards compatible Patch: Backwards compatible bug fixes only -Suffix (optional): a hyphen followed by a string denoting a pre-release version

To expand on it (my opinion):

Major - changes to API (we should not make many of them) that break the interface. This includes only user-facing functionality. Minor - new feature in API, something visible or not to the user. User visible changes would include new functions, new variable types etc. Changes not visible to users would include for example performance improvements Patch - bug fixes that do not change any API

Other changes like refactoring (of non user facing API), internal string changes etc. would not nessecitate version change.

We should also take a look at 'releasing' some of the versions so we wouldn't break people every time they update the package. However, this project is still in early stages so this might not be needed now - something to keep in mind though.

emjun commented 4 years ago

Thanks for bringing this up! I like the schema Microsoft uses/you suggested. It appears to be a version of semantic versioning and is familiar to me.

Let's move to this versioning scheme as we work towards moving to v1. It would be great to update/release more frequently (as needed) and more organically move towards mapping out new major versions, etc.