search

stefan-kolb / nucleus

Platform as a Service API abstraction layer.
MIT License
28 stars 0 forks source link

Version naming conflict #46

Closed croeck closed 9 years ago

croeck commented 9 years ago

Hi @stefan-kolb ,

while fixing minor things in my thesis I found an issue with the version naming. Currently we have used version 0.1.0 here on GitHub, whereas the API is already labeled as v1. I would now harmonize both versions and tend to rename the GitHub version to 1.0.0. The alternative, v0 for the API, seems quite awkward to me.

In consequence I would also rename the milestones. 0.2.0 would likely become 1.1. The current milestone 1.0.0 should then be 2.0

Any comments?

stefan-kolb commented 9 years ago

Hi,

I noticed this issue before. Personally, I don't have any problems with the inconsistencies because we are working towards the v1 API starting from 0.1.0 of the software. API interface version and software version will probably be different anyhow. You can still label it as 1.0.0 if you like to and we'll work on the v1 API from there from software version 1.0.0-1.99.99. The only cconcern that I would have when thinking about that scheme is that it looks like we are already stable when labeling our software version 1.0.0

croeck commented 9 years ago

The only cconcern that I would have when thinking about that scheme is that it looks like we are already stable when labeling our software version 1.0.0

Hm. Probably true. Thinking about the differences between API and software versions it also would not make sense to expect different Accept headers as soon as a minor feature is added. With semantic versioning v1 should never introduce breaking changes. Moreover, as you already said, the current version numbers 0.X.X implies that we are still not ready for production and the v1 API interface is still subject to change.

I'll keep the version numbers just as they are.