Regular releases

[ivanlanin]

I've initiated two minor releases scheduled by the first day of the month. We will release those minor versions with whatever we have done by that date. Anything we can't finish, we will put to the next version. What do you think, guys?

[ivanlanin]

We've tagged each issue with related labels. I suggest we also start to tag issues with milestone.

[ghost]

What do you mean when you say: "minor version"?

[ivanlanin]

http://semver.org/

[ghost]

Are we ready to deal with more than one development branch?

[ivanlanin]

I don't think using semantic versioning will force us to create another development branches. We will still continue using only one develop branch, but we will have more exact criteria when we're launching our releases: when it's only bug fixes, it's a PATCH; when it doesn't break any compatibility, it's a MINOR; when it does break compatibility, it's a MAJOR.

What do you think? Do you have any alternative idea?

[ghost]

I have an idea that, first of all, we must choose the only person responsible for the release management. @Progi1984 used to be that person not so long ago. Something changed?

[ivanlanin]

Nothing changed. I still think that @Progi1984 is the one that will release each version. Since we're volunteers and we are all have our own jobs, we might be off from the development for some time. If we don't have a fixed release date, we will have to wait for each other. By having a release date, at least we just have to wait only for @Progi1984 :)

[ghost]

As for me, I don't like the idea of releasing something on a regular basis. The result will be exactly the same in that case: we'll get something. The aim is not to release, the aim is to deliver announced and expected functionality. Nobody is interested in regular releases if they don't deliver useful and expected things. Previously, the idea was: we plan to do something, we announce, we implement and then release when it ready. Release dates are flexible. And, yes, we wait for each other. No internal competition. If somebody said that he will handle that, let him take his time. Of course, you may release minor versions (you call this patch) even on a daily basis - it depends on severity of isssues discovered. Feature releases, on my mind, should be planned and released with 2-3 months interval. This is exactly because "we are all have our own jobs, we might be off from the development for some time", and the least thing we want is to deal with ugly spaghetti code.

Remember, you should never believe me. You may try release every month and share your experience then. ;)

[ivanlanin]

Thanks for sharing your opinion. That's what I'm looking for. I want to know the perception and expectation from each one of us. As I said before, I've joined different teams with different approaches. I just need to know how we're going implement our releases.

So, what do you guys think about this, @Progi1984 and @gabrielbull?

[Progi1984]

I agree with @RomanSyroeshko. When we release a version, we should release functionnality and bugfixes. It's why, when a release is done, I affect issues to the next version (and you can too, if you want to implement/fix a precise issue in the next version). When all these one are closed, we can release the version and begin again. Then, we are all in, a version can come in two weeks, but if we are all off, a version can come in two months. The aim is to deliver issues closed : features or bugfixes.

[ivanlanin]

Ok. We'll drop the fixed release date.

[Progi1984]

I think we should delete another milestone than current. Why ? That permits to be not dependent of next milestone and implement in current milestone what we want.

[ivanlanin]

I suggest we maintain three milestones:

• The current one, e.g. 0.10.0, to register all current issues.
• The next minor version, e.g. 0.11.0, to register all things that we decide to put later without breaking compatibility with the current version.
• The next major version, e.g. 1.0.0, to register all things that need to break compatibility.

[ghost]

And will have one more development branch?

[ivanlanin]

For the next major version? I haven't thought about it.

[ghost]

That's what I'm talking about. If we're going to dive into three development streams (2 compatible and 1 incompatible), having one development branch is not enough. Correct?

[ivanlanin]

You're right. For the proposed scenario, I think we should have at least two branch: 1 compatible (current + next minor) and 1 incompatible (next major).

[Progi1984]

@gabrielbull What do you think about that ?

• One milestone (the current) and two branchs (develop and master)
• Three milestones (current, next minor & next major) and three branchs (master, next minor & next major)

Personnally, I think that we scatter. We are a small team (4 developers) on a small project. We are not pushing commits every day (nearly with @RomanSyroeshko & @ivanlanin ;)). A release can wait for the stability of a feature. Instead of having multiple branchs, I think we should all pull request our commits (which act as personal branchs) for bugfixes and features, and never commit directly on develop branch. That will permit to comment pull requests, and fixes some errors before pushing on the develop branch.

[gabrielbull]

I'll have to agree with you @Progi1984 . I think if we start developing on multiple branch we'll end up making mistakes. Merging multiple branch can become a lot of work and sometimes can take up to 25% of the development time, which is what we should avoid here. We can branch when we have to, bug fix on legacy release, etc.

As for not committing directly on the develop branch but using pull requests instead, this can lead to conflicts if 2 persons are working on the same files, especially if we decide to rewrite big part of code for a major release.

So, if we decide to go ahead with a major release, we should all be able to work on it and push changes to it. There is not an ideal world but I think if we decide to work on a major release, we should stop developing minor releases and focus all our effort on the major release, thus, keeping our repo to 2 branches, master and develop, committing directly to develop.

But for minor and patch releases, we can work with pull requests, I don't really see a problem.

[ivanlanin]

Thanks, guys. To summarize:

1. We will stick with two branches: master and develop
2. We will never commit directly to master except as a pull request for a new release.
3. We will commit trivial changes directly to develop and will send a pull request for big changes.
4. We will stop developing minor releases once we decide to go ahead with a major release.

Can we still keep more than one milestone labels to tag individual issues? The scenario is like this: We have "Implement ODT Reader #71". We tag this issue first as 1.0.0. When somebody starts to work on it and decides that this feature can be included in the next minor release (compatible), he will marks it as 0.10.0.

[ghost]

We will commit trivial changes directly to develop and will send a pull request for big changes.

I thought that @gabrielbull mentioned the opposite approach, because "this can lead to conflicts if 2 persons are working on the same files, especially if we decide to rewrite big part of code". Or am I missing something?

[ivanlanin]

I might also misunderstood the meaning. @gabrielbull Can you please explain?

[gabrielbull]

Roman is right, I meant to say we can use pull request for smaller changes because it has less chances of conflicting with other people's work, and if it does, it is easy to resolve.

But, if we're to rewrite a big part of the code it would be useful to commit directly to the branch because it would allow others to work on it too and conflict resolution between a minor release and a major release can be a pain in the ass.

[ivanlanin]

Ok. So basically we will commit directly to the develop branch? Is it ok if I still use pull requests like #198 and #205 just to check with Travis before merging it to the develop branch?

[Progi1984]

I agree with that.

[ivanlanin]

I leave two additional milestones, i.e. 1.0.0 and Later, just to categorize issues. The last one is for issues that we don't think we will solve on 1.0.0. Are you guys ok with that?

[Progi1984]

So we have (normally) two milestones : the next and the "Later"... If it's the case, it's ok for me !

[ivanlanin]

Yes. That's what I mean :)