Skip to content
This repository has been archived by the owner on Jun 10, 2019. It is now read-only.

Release and tagging procedure #278

Open
vorlock opened this issue Feb 4, 2016 · 11 comments
Open

Release and tagging procedure #278

vorlock opened this issue Feb 4, 2016 · 11 comments

Comments

@vorlock
Copy link
Contributor

vorlock commented Feb 4, 2016

Hi guys,

I know that lot's of good work is happening in here therefore my 2 questions:

  1. Do you have any release plans?
  2. If answer to 1 is not, do you think that master is table enough to make debs out of it once every 3-6 months? It's not like I'm pushing for anything I just see a lot of work ppl put into this project and I think it should be available via Debian repos.
@myhro
Copy link
Collaborator

myhro commented Feb 4, 2016

Hi Marcin,

I was thinking about this earlier this week, asking myself about how close we are to 1.0 since 0.9.9 was released.

Do you have any release plans?

Last year we changed our branch strategy, but I don't remember if we talked about the relationship between new code arriving at the repository and new releases. I guess it's time to make this clear.

Have you thought about this, @andsens?

It's not like I'm pushing for anything (...)

I didn't understood it that way. Your questions are absolutely relevant and aligned with the good health of the project.

Regards,
Tiago.

@andsens
Copy link
Owner

andsens commented Feb 5, 2016

Do you have any release plans?

Nothing formal, no. Until now, tagged versions have been on an ad-hoc basis when people needed them.

do you think that master is table enough to make debs out of it once every 3-6 months? It's not like I'm pushing for anything I just see a lot of work ppl put into this project and I think it should be available via Debian repos.

3-6 months sounds reasonable. Also, bootstrap-vz is already available in jessie, but it could use an update. You should definitely talk with @vorlock (Marcin Kulisz) about that, he is the current maintainer. We also discussed creating the man pages automatically through sphinx, which would be really cool.

@myhro
Copy link
Collaborator

myhro commented Feb 5, 2016

You should definitely talk with @vorlock (Marcin Kulisz) about that, he is the current maintainer.

I got a little bit confused about this... Because this issue was opened by Marcin himself.

@andsens
Copy link
Owner

andsens commented Feb 5, 2016

I got a little bit confused about this... Because this issue was opened by Marcin himself.

I... what? Oh... man, I read that issue way too quickly. Haha!
OK, in that case my answers make no sense at all since @vorlock already knows all of this :-)
I am open to suggestions on how we could handle this, I have no strong opinions in this matter.

@vorlock
Copy link
Contributor Author

vorlock commented Feb 5, 2016

:-)

If you @andsens & @myhro don't mind tagging new release when you're confident that it's ready then it'd be great.

I'm not sure what philosophy will suit you best, my personal opinion is to tag when I have new features I know ppl want to use so sometimes it's every day, but this may be over zealous and is really dependant on the speed for new features coming in etc.

Other option maybe not very rigid but preplaned release window with automated tagging or something like this every given period 3-6 months or so. I can set up my personal reminder to bug you about it every 3 months for example (I'm using taskwarrior for such tedious stuff :-) )

I don't mind to package and upload new release every so often (well maybe not each day) but having tags is a great help as it's allows me to use almost automated process for fetching applying etc. then I just have to review changes, build, test and we're ready.

@myhro
Copy link
Collaborator

myhro commented Feb 5, 2016

(...) my personal opinion is to tag when I have new features I know ppl want to use so sometimes it's every day (...)

I like the idea of tagging often. For instance:

  • Anders finished the Docker provider: tag it (increment the y in semver's x.y.z).
  • We accepted a pull request which fixs an issue, like the growpart workaround that was merged a few weeks ago: tag it (increment the z in semver's x.y.z).

We have a pretty stable code base right now, so I guess we can tag anything as long as we are confident enough that will not introduce a regression.

Personally, I would like to see the oracle provider merged before 1.0.0 (I'm already talking about this with Anders). Are there any other features that you guys would like to see finished before we reach this milestone?

@srivasta
Copy link
Contributor

srivasta commented Feb 6, 2016

I'm biased, but I'd like the admin_user branch in. I am no longer traveling, so I can work through the remaining (mostly python newbie) issues

@vorlock
Copy link
Contributor Author

vorlock commented Feb 7, 2016

To be honest I'm not sure where admin_user branch live and what's on it, but having Oracle provider and automatically generated man pages would be nice to have in the 1.0.0

@myhro
Copy link
Collaborator

myhro commented Apr 13, 2016

@andsens do you mind if I make a 0.9.10 release until we figure the version 1.0.0?

P.s.: actually I'd prefer to wait for #310 to be closed first. :-)

@andsens
Copy link
Owner

andsens commented Apr 13, 2016

@myhro, sure - go right ahead :-)
At some point I also need to make a new version for pypi. It's quite outdated :-(

@myhro
Copy link
Collaborator

myhro commented Apr 13, 2016

Anders, I forgot to ask you: do you have a GPG/PGP key? As GitHub now supports signed tags/commits verification, we can start doing this when tagging new releases (and the signature can also be used to verify the tarballs fetched from here when updating the Debian package as well).

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

No branches or pull requests

4 participants