Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release management #243

Open
mfrey opened this issue May 16, 2018 · 2 comments
Open

release management #243

mfrey opened this issue May 16, 2018 · 2 comments
Assignees
Labels

Comments

@mfrey
Copy link
Collaborator

mfrey commented May 16, 2018

Is there a rationale behind the version numbers? As far as I understood, we are on 2.0.0 since a lot of code has been re-organized, rewritten, etc. I'm wondering what the next release after the "this is the last NFN-supported release" of ccn-lite would look alike.

We should define a "release management" process and document it in the wiki. I'm all in for keep it low overhead, but it should a) be clear what the version numbers mean, b) a process defined and in place how we plan our releases (e.g. a milestone per release which contains issue numbers we would like to see to be resolved in this release). Any thoughts?

@blacksheeep
Copy link
Contributor

I think there wars a rational behind those numbers.
we had 0.1.0, 0.2.0, 0.3.0 as alpha releases and for feature updates.
we had first number increasing for project structure change and we got to '2' because the first version just never left alpha status.
we would increase last number for bugfixes.
next version would be 2.0.1 if only bugfixes or 2.1.0 of features changes.

This we already changed a lot, it will be 2.1.0

@blacksheeep
Copy link
Contributor

blacksheeep commented May 16, 2018 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants