search

yjmantilla / sovabids

A python package for the automatic conversion of EEG datasets to the BIDS standard, with a focus on making the most out of metadata.
https://sovabids.readthedocs.io/en/latest/
BSD 3-Clause "New" or "Revised" License
9 stars 3 forks source link

Software Versioning #39

Closed yjmantilla closed 2 years ago

yjmantilla commented 2 years ago

As of now I dont have a system of numbered versions for the software. Luckily bidscoin provides an example on how to do this; I just have not had my mind around it. The versioning could actually be another target for the final gsoc deliverable (it is quite important, i hope is not hard to implement). Guess this would be version 0.1 of sovabids hehe.

Also, there is the idea of flagging bad versions, as @civier proposed:

I don't know if you're familiar with fMRIprep, but it's the most popular software to do pre-processing of functional MRI data. In any case, it has a nice function that allows the developers to flag a bad version (i.e., a version that was distributed, but found to be problematic retrospectively), such that the users will see a warning message when trying to use it.

For example, conversion 20.2.1 was flagged, and when trying to use it, it displays the following: You are using fMRIPrep-20.2.1, and a newer version of fMRIPrep is available: 20.2.3. Please check out our documentation about how and when to upgrade: https://fmriprep.readthedocs.io/en/latest/faq.html#upgrading WARNING: Version 20.2.1 of fMRIPrep (current) has been FLAGGED (reason: Functional outputs in standard space can be wrong depending on the original data's orientation headers - see https://github.com/nipreps/fmriprep/issues/2307). That means some severe flaw was found in it and we strongly discourage its usage.

stebo85 commented 2 years ago

I am a big fan of semantic versioning :) https://semver.org/

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards compatible manner, and PATCH version when you make backwards compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

yjmantilla commented 2 years ago

Hmm so if currently lets say we are at sovabids 0.X.Y, when we launch the new rules file format it would be already sovabids 1.X.Y ? Im a bit scared of having a '1' already hehe

yjmantilla commented 2 years ago

As per what the website says:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.

@stebo85 Maybe we should stay on the 0.X.Y for now, since it is quite experimental still. If the final GSoC is sovabids 0.1 , the implementation of the new rules file would be sovabids 0.2

yjmantilla commented 2 years ago

I ended up using versioneer and to manage the semantic version one cause use git tags . Im still getting around the concept but as of now it works!

I decided to label the current version as a prerelease (alpha software). So I added an 'a' to the end

So in general what I understand is that I use git tag to comply to semantic versioning and versioneer manages the more detailed stuff through its system.

If you go to https://sovabids.readthedocs.io/en/latest/ you will see the version at the upper left corner.

Closing this, but if you have any feedback on this , let me know.