Software Versioning: Proposal

Introduction

Version number can be a confusing matter, specially because there are many ways to do it and at the end it is a matter of personal (or team choice). After doing some digging in python PEPs and internet in general I found this Wikipedia site on Software Versioning that to me makes a lot of sense and what I propose here is the following:

Pipeline Versioning.

Let's define our goal to be the version 1.0 as the one that will be stable, portable and also must contain an automatic wavelength calibration module as well as a flux calibration module. Besides, the list of issues tagged as bug, or enhancements should be at least 70 ~ 90% closed. That is a large gap but some enhancements might be of less importance, bugs will be naturally prioritized.

According to the Wikipedia site and the current status of our development the number would be something like this:

1.0a1 which can be read as "we are developing towards version 1.0 and currently we are working on the alpha version of our pipeline" then it will naturally evolve to 1.0b1 once we have the beta version working and finally we should have our version 1.0. For smaller changes, say, we introduce a larger modification during the beta stage, that new version should be named 1.0b2 and so on.

Right now numbering is a mere formality and I have been experimenting in introducing them since some time ago, but when they start to count will be after our first release which will be the first beta version at the beginning of June 2017.

Summary and Schedule

• 1.0a1 until the end of May 2017.
• 1.0b1 From beginning of June until end of August (last digit may vary)
• 1.0 Sometime between September and before the end of the year (ideally October).