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

Switching to a regular release schedule #524

Closed
stefankoegl opened this Issue Oct 31, 2017 · 13 comments

Comments

Projects
None yet
5 participants
@stefankoegl
Copy link
Member

stefankoegl commented Oct 31, 2017

Releases of SoCo have been rare and far between (#442 Nov 2017, #315 Oct 2016, #278 June 2015, #238 Nov 2014).

@KennethNielsen suggested switching to a fast release cycle. I agree with this in general, and would like to discuss how this could be implemented.

I'd like to start with a proposal, and hope for your comments, alternative suggestions, etc.

@stefankoegl

This comment has been minimized.

Copy link
Member

stefankoegl commented Oct 31, 2017

Quarterly releases

My proposal for this is to switch to regular, quarterly releases. We define release months and aim for a release in the first half of that month. Whatever feature / change is ready until then gets merged and shipped. What is not ready does not delay the release, and waits for the next one.

What we would need

  • a release schedule
  • other volunteers for doing the releases, as I might not always be available
  • possibly a review of the release procedure
@lawrenceakka

This comment has been minimized.

Copy link
Contributor

lawrenceakka commented Oct 31, 2017

Completely in favour of this. Although I have not been around much recently due to pressure of work, I have kept an eye on the bug reports, and quite a number are a result of people running the last official release where bugs are already fixed in dev. This should reduce those reports.

@KennethNielsen

This comment has been minimized.

Copy link
Member

KennethNielsen commented Oct 31, 2017

I would be in favor of any change that would lead to less time between releases. A fixed schedule could be one way to go. I might worry (a little), that it would be a bit too rigid, and therefore something that we might end up not complying with. It also depends on how much work is actually entailed in an release. @stefankoegl can you comment on that, roughly how much time you use on it, varying of course with the amount of changes.

No later than X time from last release

An alternative (which I'm not sure I think is better, but at least something to consider) is to set the release date to no later than 3 months from the last release. That way, if things get delayed, we wont have to worry about getting out of alignment with the release schedule, and if we want to release earlier, because of important bug fixes, we can do that as well.

@KennethNielsen

This comment has been minimized.

Copy link
Member

KennethNielsen commented Nov 20, 2017

@stefankoegl could you comment on the approximate time you use on actually making a release. Also, as far as a review of the release procedure goes, you are probably in the best position to drive that. Would you mind? I can certainly help with input. If there is an updated release procedure and it doesn't take an enormous amount of time to do, I can help with the releases.

@KennethNielsen

This comment has been minimized.

Copy link
Member

KennethNielsen commented Nov 20, 2017

Does anyone have any more input into this discussion. Another release scheme or comments on the two suggested ones?

@stefankoegl

This comment has been minimized.

Copy link
Member

stefankoegl commented Nov 20, 2017

@stefankoegl could you comment on the approximate time you use on actually making a release.

The most time consuming part of the release procedure is doing the release notes. We usually have an issue where short descriptions of changes are added. However I usually also verify the change log to make sure that there's nothing missing (and usually there is something). Also sometimes text needs to be reprased, formatted in restructured text, etc. For 0.13 this has taken me somewhere between 30 and 45 minutes, but it scales linearly with the size of the release. The rest of the procedure should be done in 15min total. So all together 1h max.

@DPH

This comment has been minimized.

Copy link
Member

DPH commented Nov 20, 2017

Firstly thank you for getting release 0.13 out - it simplifies support to get people using the latest release.
I fully agree with more regular releases and no later than 4 moths from last release would make sense.
If we target every 3 month then if people are busy we can still fulfil our objective, and as @KennethNielsen says by doing no later than x from last release we don't get out of step.
With Voice control on Alexa now and I expect on other platforms this may create a flurry of changes for SoCo. If so we then have the option to do releases even more frequently.
I would suggest we put on the release notes the targeted date (e.g. target release: end February 2018 for 0.14) . Often people like to have a deadline to work to to try and get a change in.
Is there anything we can do to help get the release notes structured correctly to save time on the release procedure? I would be happy to review these - as we go if that would help.

Cheers David

@KennethNielsen

This comment has been minimized.

Copy link
Member

KennethNielsen commented Nov 20, 2017

@stefankoegl would you be ok with the, 3 months from last release, but with the option to release earlier, if something sufficiently important comes up, or do you think it will annoy people, potentially working towards a deadline?

@DPH what might help, is if we try to keep a draft of the release notes in the first comment of the release notes thread. That way, we can still ask people to add a comment, and someone (you if you want to) can re-phrase and edit as we go along.

@KennethNielsen

This comment has been minimized.

Copy link
Member

KennethNielsen commented Jan 6, 2018

Any of the options here are better than what we have and I think we should move forwards with a decision. @stefankoegl do you have opinions about which you think is best.

@stefankoegl

This comment has been minimized.

Copy link
Member

stefankoegl commented Jan 16, 2018

Thanks for your comments! I now see the point of @KennethNielsen's suggested "No later than 3 months from last release" scheme, and I think that we can go forward with it.

@stefankoegl

This comment has been minimized.

Copy link
Member

stefankoegl commented Jan 16, 2018

Based on the last relese #442 on Nov 19, 2017, this would mean that the next one (#538) is scheduled for February. I'll set Feb 17 as the target date as it is a weekend.

@KennethNielsen

This comment has been minimized.

Copy link
Member

KennethNielsen commented Jan 16, 2018

Great. We should probably leave the issue open until we have added some documentation somewhere.

@stefankoegl

This comment has been minimized.

Copy link
Member

stefankoegl commented Feb 25, 2018

I've just updated the documentation for the release procedure in ef0f17d.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment