search

snaekobbi / pipeline-mod-braille

ARCHIVED. Please don't make any new issues or pull requests in this repo.
0 stars 0 forks source link

Make frequent releases #47

Closed bertfrees closed 8 years ago

bertfrees commented 9 years ago

Going one step further would be to not ever have SNAPSHOTs in the master branch.

dkager commented 9 years ago

Going one step further would be to not ever have SNAPSHOTs in the master branch.

I think it is enough (and even desirable) to have predifined points in time where topic branches are merged into master, so that work in the next iteration can be based on that. Of course this could lead to having to do integration patches before your code is even finished, but on the other hand it avoids a rush of fixing merge conflicts and regressions right before pushing out a stable release.

Also:

bertfrees commented 9 years ago

Specify module versions in all POMs

What do you mean with that?

Base master on stable version of modules.

Yes, that's what I meant with "not ever have snapshots in the master branch". For external modules that's a good idea, for internal modules that's maybe too limiting, we'll see how it works out.

dkager commented 9 years ago

Specify module versions in all POMs

What do you mean with that?

I mean that we need to know what versions of external components are pulled in. If we build with liblouis 2.6.2, then code should work with that version. If it is changed to 2.6.3, then that version needs to be made to work. But IMO one development cycle (iteration) should stick with the same external dependencies, at least on daisy/pipeline-mod-braille/master. Which brings me to my next point...

I think snaekobbi/pipeline-mod-braille should have a master branch. We could do continous integration on this, e.g. using the eXtreme Programming approach. Developing features in topic branches is great, but if releases are made only once every few months we should probably strive to do more frequent integration ourselves. Integration testing is important, and for this the master branch could be used. AFAIK we don't have such a branch at the moment.

bertfrees commented 9 years ago

We know the versions of external components, they are defined in bom/pom.xml, which is imported via the parent.

Master is owned by daisy. Me and Romain are the only ones who are pushing to it. If you mean having a master in snaekobbi which is not an exact copy, then I wouldn't call it master. But anyway, whatever it's called, what did you have in mind for it? I don't know extreme programming, so maybe you can explain your ideas during next developer call and then we can discuss it?

Do you mean we would be using that branch as the base from which we release? The idea is to be making a release every few weeks from now on, but I'll simply do that from the actual master.

The test suite contains a mixture of unit tests and integration tests by the way. It is continuously run on Travis (for the master branch). Locally they can be run on any branch of course.

dkager commented 9 years ago

A brief explanation of what I meant: Say you did some work on the framework and API of mod-braille. Just after that I want to implement a feature that uses your new code. To do this I would have to merge your branch, fix any merge conflicts, then do my work. If many people start doing this it becomes hard to know which branch has which code in it. Hence why I suggested to have a master branch for Snaekobbi, or alternatively to have frequent releases in the upstream (DAISY) master branch.

bertfrees commented 9 years ago

OK this is exactly the kind of problems I have to deal and which I had in mind when writing https://github.com/daisy/pipeline-mod-braille/issues/30#issuecomment-112084215. It's also one of the reasons I wrote in the meeting notes from 2015-06-04 that I want to avoid a lot of long-lived feature branches.

I'm not convinced though that having a common branch as you describe is a neater solution. More frequent releases (as the title of this issue suggests) is the way to go I think.

We'll discuss this further in the next call.