Loomio

Fixed schedule for bugfix releases

DS
Dennis Schubert Public Seen by 419

I am happy we are in the final phase of our 0.5.0.0 release which will bring a lot of bug fixes and new features. While we (as in "the developers") are really happy about the release, some community members raised questions about our release management. The last (non-hotfix) release was made in September 2014, so we just reached the 7 months between two releases. This is probably nothing we want to do in the future.

At the moment we release a new version whenever "it feels right", which is rather rare as preparing a release usually requires a fair amount of work and since we are still a relatively small developer group, nobody wants to do this job. Because of the lack of developers, it can take quite a large amount of time for features to be "ready to release", which might delay releases even further.

The chat is a good example for that. I am sure we would have released some months ago if we decided to ignore the chat, but we thought we would be able to finish the chat within a short amount of time and include it in the "next" release. I feel like we got trapped in a "just wait a week and it will be done" circle here.

Obviously, we are not able to finish features faster since we simply do not have the resources to work on feature like we would love to do and I think we are doing actually pretty fine. However, polishing work on features in the develop branch will block releases since there is no simple way to do a release without given feature. We decided to disable the chat per default for now, but that is not a good solution for future feature developments.

Releasing new features twice a year is not a big deal. However, 0.5.0.0 contains a serious amount of bug fixes. A nice example is #5209, which will really improve the federation. This pull request got merged at the end of September and is waiting for release since that day. There are a lot of other bug fixes waiting for a long time and I think this is an issue. Having to wait a half year for annoying bug fixes is also affecting our user base, since we usually have to respond with "oh, that is fixed in the next release" and they still have to wait several months until the bug is actually fixed for them.

Because of the bad situation described above, I am proposing a fixed release schedule for bugfix releases. I have not worked out the details yet, but we do have Loomio for collaborative decision making and planning purposes, right? :) The idea is simple: release new versions containing bug fixes only based on a fixed schedule. It is important to have clear rules on what to include in a bugfix release. Some requirements out of my head:

  • The releases should not include added features at all. New features usually tend to be buggy when released by a small developer group in a fixed schedule.
  • Releases should not cause any trouble for the podmins. Updating sources, bundle install and restart the server is all they should need to do.
  • Migrations, if required, should take less than 5 minutes on an average sized pod.

Triggers to disqualify stuff to be included:

  • Additional intervention is required by the podmin. That may be changes in config files, setting up additional services, ...
  • Stuff that requires long migrations.
  • Changes on the way features work or look. As an example, I would not like to see the bootstrap migration included in a bug fix release.
  • Changes on components which are not covered by tests.

I suggest a fixed schedule of 6 weeks, with 1 week of code freeze before release to give developers and enthusiastic podmins the chance to try the release candidate and spot regressions. I do not think shorter cycles would be better since we do not have that many changes happening. Longer release cycles might appear too slow.

Fixed release cycles sound fancy, I know. However, there are some drawbacks we have to think about before establishing a "release management". Obviously, we need someone to be responsible for matching the schedule and releasing the stuff on time. This person (or this group, although I do not think we need a lot of human power right now) should also be in charge of the decisions on what to include and what not. As I am pretty useless for the project at the moment and I would like to put a little bit more effort into our project, I would do this job.

The second, and bigger issue, is code management. We are not able to base our releases on the develop branch since we do have feature development going on there. I do not think it is good for us to add strict rules for feature integration branches, we do not have enough developers to really polish features off the main branch. I have not figured out a nice way without having a large mess in our repos, but as far as I can tell right now, having a bugfix-release branch and cherry-picking commits in is probably the best way. But that is just an idea, not a fixed rule.

Although this is a pretty large text, it is just an idea I had while talking to some people about diaspora and the "slow" releases. I am not going to start a vote now, as I feel we should collect further ideas first. I would love to hear your feedback regarding the include/exclude guides and the code management as well. Other comments are welcome, too, of course.

F

Flaburgan Tue 21 Apr 2015

I cannot agree more with you that we need to release more often. To see awesome improvements blocked during months is sad. I'm not sure hotfix releases is the way to go though. Would you have included the federation improvement in it? This looks to big to be an hotfix to me. So maybe we should have another branch like you said, but a "minor-release" branch instead of hotfix, and without scheduling the release date, just keeping in mind that if the minor seems stable and important enough, we should release it. This is kind of what we did with the montly meeting "should we release", but we were blocked by the state of the develop branch.

Both solution implies to maintain a separate branch from develop, which is more work though :(

F

Flaburgan Tue 21 Apr 2015

Oh, and I agree that minor (or hotfix) releases should not imply anything else than bundle, small migration and assets compilation ;)

DS

Dennis Schubert Tue 21 Apr 2015

Would you have included the federation improvement in it? This looks to big to be an hotfix to me.

This was a very small pull request and it is clearly fixing bugs. Also, I never used the term "hotfix release" in my proposal. I am talking about bugfix releases, not hotfix releases. Hotfixes remain to be reserved for security critical issues or regression fixes with huge impacts. Hotfix releases are never scheduled, which is why they are called hot fix...

G

goob Tue 21 Apr 2015

I think this is a great idea. However I had always had the impression that it would not be possible (or at least, not easy) to separate bug fixes for a separate release in the management system Diaspora uses. If the project can find a good system for doing this, the proposal has my full support.

I think it would be good to look at implementing code for new features in such a way that a delayed or abandoned feature can never hold up a major release. In this case, if chat has proved to take far longer to polish than anticipated, keep its code separate enough during development that it can simply be omitted from the code when the release branch is created. Again, I don't know whether this would be possible, but I'd hope so.

F

Flaburgan Tue 21 Apr 2015

I never used the term “hotfix release” in my proposal

Okay so we are talking about incrementing the minor number of the version here, nice.

DS

Dennis Schubert Tue 21 Apr 2015

@goob Dude. Let me quote myself. ;)

I do not think it is good for us to add strict rules for feature integration branches, we do not have enough developers to really polish features off the main branch.

I wish we would be able to develop each feature in a separate branch and merge only when it is 100% done, but we are not able to do this.

And acutally, cherry-picking commits is not a big deal. The main "issue" here is the fact our bugfix release branches would diverge from the master/develop branches. That's not an issue and that's how most big projects do their backports (Rails, for example), but someone here might have an even better idea.

F

Faldrian Tue 21 Apr 2015

So to understand how this would work... you cherry-pick bugfixes into a separate branch and every $n weeks there is a bugfix-release. When the feature/regular release is released, the bugfix-branch is set to the current release branch. Then the cycle starts over and the bugfix-branch is filled with new cherry-picks again?

DS

Dennis Schubert Tue 21 Apr 2015

@faldrian: Something like that, yep.

F

Faldrian Tue 21 Apr 2015

I like the idea (since I was one of the contributors waiting for several months for their fixes to show up in a release ... and every time be reminded of the waiting fix when the bug occurred again...). :)

G

goob Tue 21 Apr 2015

Let me quote myself.

Sure, Dennis, I read that. I was just giving my thoughts, which happen to be different from that. I know I'm not a developer, and you're almost certainly right and I'm probably wrong, but hey, what's Loomio for if not thinking aloud?

If cherry-picking commits is easy, that's fine. I had imagined that it would be difficult to ensure that none of the code merged into develop from a developing feature would adversely effect the performance of the app when removed, hence it would be better to develop completely new features (certainly major ones such as chat) in separate branches. But hey, I guess that's what the code freeze week is for. Whatever is the best practical solution for Diaspora, I'm happy for that to happen!

And thanks a lot for offering to manage this process!

DS

Dennis Schubert Tue 21 Apr 2015

Thanks for your thoughts!

I don't fear any performance issues. Also, I don't really expect things to break, because I'd only qualify commits for backporting when the code is covered by tests. We might get some merge troubles on cherry-picking, but since our bugfix comments are usually rather small, I don't worry about it. It is possible that we are unable to merge a bugfix at some point, for example after large code refactorings. However, these changes are rather rare and they might indicate that's time for a large release.

JR

Jason Robinson Sun 26 Apr 2015

Totally would love to see this happen. A dedicated person is a good idea, and I'd totally trust Dennis with this job!

We need to push out minor increments out faster.

DS

Dennis Schubert started a proposal Sat 2 May 2015

Establish a fixed release cycle Closed Mon 18 May 2015

Outcome
by Dennis Schubert Tue 25 Apr 2017

Establish fixed releases as proposed.

Proposing the implementation of a fixed release cycle as drafted in the discussion with more clarification:

  • Release "bugfix" releases as regular minor releases (x.x.y.0) every sixth week with 1 week of code freeze.
  • Include features that do not require schema changes in those releases, so we're able to release features like the aspect sorting fast.

Results
Agree - 14
Abstain - 14
Disagree - 14
Block - 14
15 people have voted (14%)
DS

Dennis Schubert
Agree
Sat 2 May 2015

PP

Pirate Praveen
Agree
Sat 2 May 2015

KAK

Karthikeyan A K
Agree
Sat 2 May 2015

Actually this is a good idea. I'm with it. Brings in disciplined and matured development. But wonder it may retard some true hackers.

F

Faldrian
Agree
Sat 2 May 2015

JR

Jason Robinson
Agree
Sat 2 May 2015

Awesome

JR

Jason Robinson Sat 2 May 2015

Though I'm not sure why "no schema changes" - since mostly afaik they are fast. I think it should be case by case, but this is a good start :)

W

Waithamai
Agree
Sat 2 May 2015

JH

Jonne Haß
Agree
Sat 2 May 2015

S

SuperTux88
Agree
Sat 2 May 2015

DU

[deactivated account]
Agree
Sun 3 May 2015

F

Flaburgan
Abstain
Sun 3 May 2015

I agree we should do minor release as described here (only small update steps) more often, so we have to maintain to separate branches and be able to release whenever we want, but a fixed date is maybe not appropriate, if there is nothing to push...

Y

y.semin
Agree
Mon 4 May 2015

BC

Balasankar C
Agree
Tue 5 May 2015

FS

Florian Staudacher
Agree
Tue 5 May 2015

SVB

Steffen van Bergerem
Agree
Thu 7 May 2015

NR

Nicholas Riegel
Agree
Thu 7 May 2015

Suggest monthly on a specific date (ie: every 10th day of the month). Gitlab (another very popular open source Rails app) releases on a specific date. It seems to work well. (https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/release/monthly.md)

F

Flaburgan Tue 12 May 2015

I'm happy we are going to have bugfix releases more often :)

Small points I wanted to discuss though:

  • I thought those minor releases were only about bugfix, or really small features (re-add aspect sorting for example, which is more a fixed-regression than a feature). I'm surprised to see follow tags on mobile (18 files changed) and manage tags on mobile (12 files changed) added in a minor release. So what's the exact rules to decide what should be included or not?
  • The 0.5.99.0 for develop code before 0.6.0.0 and 0.5.0.99 for stable code before 0.5.1.0 really looks weird to me. Those are valid version number which could be used to tag a version. Why don't we simply use 0.5.1.0-dev and 0.6.0.0-dev?
DS

Dennis Schubert Tue 12 May 2015

The proposal is pretty clear, no reason to be surprised about that:

Include features that do not require schema changes in those releases

0.5.1.0-dev and 0.6.0.0-dev are no valid semantic version numbers and break numeric sorting. We will never have a 99th hotfix or a 99th minor release level. If we do, we really have to think about our development and our code quality. ;)

Using .99 is a popular way of tagging new releases, Wireshark is a popular example.

F

Flaburgan Tue 12 May 2015

break numeric sorting

It doesn't as it's evaluated from left to right

JR

Jason Robinson Tue 12 May 2015

I have to say I dislike the .99 notation more every day I see it in the lists. 0.6.0.0-dev and in the case of an RC, 0.6.0.0-rc, sound great to me.

DS

Dennis Schubert Tue 12 May 2015

I see we need a proposal on version naming when the current proposal is closed. :)

S

SuperTux88 Tue 12 May 2015

With -dev and -rc the versions are sorted this way:

0.5.0.0

0.5.0.1

0.5.1.0

0.5.1.0-dev

0.6.0.0

0.6.0.0-dev

0.6.0.0-rc

F

Flaburgan Sat 16 May 2015

@dennisschubert the current proposal has to be closed first.

JR

Jason Robinson Sun 17 May 2015

Could we shorten or close this proposal as no one is clearly objecting? :)

DS

Dennis Schubert started a proposal Tue 19 May 2015

Use x.y.99.0 and x.y.z.99 for future release numbers instead of a "-dev" suffix Closed Tue 2 Jun 2015

Outcome
by Dennis Schubert Tue 25 Apr 2017

Stick to .99.

Proposing to use x.y.99.0 and x.y.z.99 for future release numbers instead of a "-dev" suffix during the developing cycle.

Pros:
- Numeric sorting will work properly.

Cons:
- Looks "different".

I don't think we'll ever hit a .99th bugfix or major release, so this is not an issue.

Results
Agree - 8
Abstain - 8
Disagree - 8
Block - 8
15 people have voted (14%)
DS

Dennis Schubert
Agree
Tue 19 May 2015

S

SuperTux88
Agree
Tue 19 May 2015

JR

Jason Robinson
Disagree
Tue 19 May 2015

I prefer a more standard way (in my view at least). I'd be ok with prefixing ie dev-0.6.0.0 too, but .99 just looks weird :)

F

Flaburgan
Disagree
Tue 19 May 2015

the release is going to be 0.5.y.0, so we should call it that way and add -dev to say it's not released yet.

BC

Balasankar C
Disagree
Tue 19 May 2015

.99 in the version number?? That doesn't feel right. -dev suffix would be better.

JH

Jonne Haß
Agree
Tue 19 May 2015

SVB

Steffen van Bergerem
Agree
Tue 19 May 2015

DU

[deactivated account]
Disagree
Wed 20 May 2015

As a developer (albeit not in ruby) I'm not a fan of .99 either I'm afraid :(

F

Faldrian
Agree
Wed 20 May 2015

Looks ugly, but when you think about it as "the number is bigger when there is more good stuff in it" - it makes totally sense. :)

W

Waithamai
Agree
Wed 20 May 2015

FS

Florian Staudacher Wed 20 May 2015

I really don't feel strongly about one way or the other ;)

C

Chocobozzz
Disagree
Tue 26 May 2015

-dev is more intuitive

V

ventos
Abstain
Mon 1 Jun 2015

TS

Trolli Schmittlauch
Agree
Mon 1 Jun 2015

This is a commonly used scheme e.g. in the KDE world.

EG

Erwan Guyader
Abstain
Mon 1 Jun 2015

R

Ravenbird
Agree
Tue 2 Jun 2015