[qsr_lib] Version 1.0?!
Closed this issue · 30 comments
About the backward compatibility, if we merge #107 and if how the qsrs_for work is changed as in #114 then we might consider making tabula rasa and increase the version number to 2.0 and also scrap all the deprecated function calls and assignments. With all the recent changes it becomes a lot to maintain as you rightly stated, @yianni, so we might as well get rid of everything that is no longer supported.
About the thing of #107 blocking other PRs, I see two possibilities:
- Wait until #107 is merged and then implement it, taking the new format into account
- Implement current PRs with the old format and rebase and alter #107 before it is merged
I don't think that any of the two is particularly more work than the other.
I'll leave this here for discussion.
We could also switch to the dict based output and scrap the strings which would remove some overhead as well.
For version 2.0 it might be worth creating a milestone / release for the current version. This way people who are using it will still be able to use it, whilst people wanting to upgrade to 2.0 can just pull the most recent version.
Could just release it as it is now, this would create a tag which people can checkout when downloading the repo or can just install the specific version via apt-get.
TL'DR: In favor of all said above, but we are still far from 2.0 version. I would prefer to work towards a 1.0 version first.
In more detail...
Given we are in the 0 cycle, I would aim towards a v. 1.0 at first, although if we want to jump straight to 2.0 I would also be happy with that given that 1.0 usually follows the principles of the 0. cycle.
Just a few things on top of my head for v2.0:
- Remove deprecated things
- Big one: I'm in favor of
--futureas being the standard with no legacy support - Documentation
In fact before moving into future I would prefer doing the documentation first, release a 1.0 version then make --future the default one and remove support for legacy.
Regarding the documentation I am waiting for #107 as there are so many conflicts to resolve with my doc branch.... once I make a doc PR the rest of bits and pieces can be filled in by all.
On a side comment anyone has a clue why if you go to the releases page the latest release defaults always to 0.0.4?
That's just the last time a release tag was added.
I just realised that the current version is 0.1.? So it would most likely be a 0.2.0. I thought we already were at 1.0.0, my bad.
That's just the last time a release tag was added.
I see. Thanks. Needs to be changed at some point then I guess.
I just realised that the current version is 0.1.? So it would most likely be a 0.2.0. I thought we already were at 1.0.0, my bad.
No worries. Yes we are still in the 0.x cycle, and next release after the merge of #107 should be 0.2.
No harm having a 1.0 milestone though. I'll go ahead and create one and feel free to add issues associated with it.
The release you are talking about is one that you manually did via github at somepoint: https://help.github.com/articles/creating-releases/
The real release via jenkins is not reflected here. Usually it is the highest tag number. See here: https://lcas.lincoln.ac.uk/jenkins/portlet/dashboard_portlet_3038/ for jenkins releases.
The release you are talking about is one that you manually did via github at somepoint: https://help.github.com/articles/creating-releases/
Thanks. Crap. Anyone knows how to get rid of it?
You can release arbitrary tags as well, you can just add a new one for tag 0.1.1 for example. Not sure how to delete it.
On the repository homepage, click the release link. On the Release page, click the name of the release you wish to delete.In the upper-right corner of the page, click Delete.
On the repository homepage, click the release link. On the Release page, click the name of the release you wish to delete.In the upper-right corner of the page, click Delete.
OK let me see how this works.
On the repository homepage, click the release link. On the Release page, click the name of the release you wish to delete.In the upper-right corner of the page, click Delete.
Is that gonna mess up jenkins?
Nothing to do with jenkins.
Great. Finally, beatiful, whole tree is expanded now.
So, rename to v1.0 linking to milestone? (or close and make a new issue).
I'd also create a 2.0 milestone, and go through the current issues and assign them to either V1.0 or V2.0 so that we know which issues should take priority. (I would do it, but I don't have permissions to)
Just to clarify, the V2.0 milestone, it just a way of labelling everything else that isn't part of V1.0
What Pet said, create a milestone v0.2.0 and then we add everything that voids backward compatibility in there.
About the thing of #107 blocking other PRs, I see two possibilities:
Regarding this, I am already changing in a branch from the current in #107. Not sure how 1 will work with it after merged (I hope it won't recommit the same commits). Alternative as 2 I could merge/push changes to #107, which I would not prefer as #107 has a specific task which on top and most importantly is not backward-combatible.
What Pet said, create a milestone v0.2.0 and then we add everything that voids backward compatibility in there.
You mean v2.0 or v0.2.0?
V2.0 as we're jumping to v1.0 for the release. (I think)
That is not what I meant with the second point. I meant that you can merge any PR now as long as they adhere to the current version and format of lib. Once we decide to merge #107 you rebase your changes ontop the current state of the lib and make the necessary changes to eventually added functionality so it all conforms with the previous changes in #107. But that is up to you.
The way I see it. Next release will be 0.2.0 after #107 (and maybe a few others). v1.0 requires more work. v2.0 will be deprecating things and make it non-backward compatible to v1.0.
regarding the version numbers, my opinion:
v0.1.2: release of current state of lib
v0.2.0: New version that is not backward compatible with current one
v1.0.0: Long term goals
v0.1.2: release of current state of lib
v0.2.0: New version that is not backward compatible with current one
v1.0.0: Long term goals
That's how I think too (see post above). v2.0 is a bit far to worry about... I would worry about 0.2 and v1.0.
That is not what I meant with the second point. I meant that you can merge any PR now as long as they adhere to the current version and format of lib. Once we decide to merge #107 you rebase your changes ontop the current state of the lib and make the necessary changes to eventually added functionality so it all conforms with the previous changes in #107. But that is up to you.
I see. Well I am changing on an offspring branch from #107 . Will need your help with something so I will push in my repo soon and you can do something. Will let you know there.