search

ohnosequences / mg7

Configurable and scalable 16S metagenomics data analysis
https://goo.gl/y3rZFD
GNU Affero General Public License v3.0
3 stars 3 forks source link

Release 1.0.0-M3-fair-LCA-top-hits #60

Closed eparejatobes closed 8 years ago

laughedelic commented 8 years ago

I don't like these sudden releases. If we won't have a clear workflow regarding this and make releases without any review and control at random points of time, nothing's going to work.

eparejatobes commented 8 years ago

I can relate to that, but it is not a good idea long-term. We actually need more releases. Plus, there's nothing to review in what I did here; just writing release-y stuff and minor cleaning.

There are 102 commits between M2 and this, and it is impossible to do any serious testing without stable versions (actually, we shouldn't ever publish SNAPSHOTs).

laughedelic commented 8 years ago

I can relate to that, but it is not a good idea long-term. We actually need more releases.

I agree about more frequent releases, but I'm talking about planning and releasing workflow.

it is impossible to do any serious testing without stable versions (actually, we shouldn't ever publish SNAPSHOTs)

I agree about publishing commit-versioned artifacts (once we have https://github.com/ohnosequences/nice-sbt-settings/issues/35).

But I'm trying to plan releases here and maintain them well (tags, milestones, release notes with references to the PRs, not just git-log). And I'm not happy either about postponing them, but so far my planning fails, because we keep adding features to each milestone on the way and things get rolling changing all the time.

You can see that M2 was also big (79 commits since M1). I was already thinking about making releases between milestones on each added feature/fixed bug. And I guess, that's what I'm going to do after M3. My point is that a spontaneous release with some funny version suffix and a git-log instead of release notes doesn't help anything. It helps you to fix something right now, but "it is not a good idea long-term".

eparejatobes commented 8 years ago

A version should only be a human-readable shortcut for a commit. Planning development is a different thing, but it should not affect releases; it is actually the other way round: what happens modifies plans, and at the very least confirms (or not) their validity.