Understanding your Workflow

[dodgex]

Hello Guys,

I'm a big fan of AndroidAnnotations, I use it in my own Apps as well in the App we develop in the company where i work.

As I'm also adding PRs i would like to understand the Workflow of how you handle PR and new Versions to get the subjects of a PR to the users.

My first PR was more or less a test to see if I can handle the way AA works while not really needing the changes for my project - this one got merged relatively fast (~12days).
My second one - with changes i actually needed - was first proposed on Oct. 6 2013 with an update after merging the refactoring PR on Dec. 12 2013. The merge happened on Mar. 16 2014, about 160 days later.
The current PR(actually two seperate but related) was proposed on Mar. 2 2014 and is not yet(~120days later) merged - but it seems that a merge is in the near future.

While i understand that most of the work on AA is done in freetime, i would like to understand the politics behind when to merge a PR and when a new release is done. I have no problem with using a SNAPSHOT(i actually started with 3.0-SNAPSHOT and never had a stable 😞) but since Oct 6. I'm forced to use a self built SNAPSHOT to have my changes available in my projects.

TL;DR
I would like to know how you decide when to merge a PR (after they are OK/LGTM) and when there will be a new release or at least a bump to the next minor snapshot (like 3.1.0-SNAPSHOT) where changes for the corresponding release will be merged as soon as they are OK/LGTM. For breaking changes (like a plugin system) that would require a new Major i understand that they will open for a bit longer until there is enough to justify a jump to a new major release.

Thank you all for this beautiful library! ;)

@DayS @yDelouis

[yDelouis]

I don't know if there are rules for considering PR and merging them.
@DayS is the only active official collaborator of this project and he seems very busy. So, @WonderCsabo and I are helping him submitting PRs, dealing with some issues and giving our opinion on PRs, but we can't do more and have to wait for @DayS for merging PRs and closing issues.

About releases, a milestone is set to issues (and related PRs). When enough features are set to a milestone, a new milestone is create for the next version. When all issues (and PRs) of a milestone are closed, a new version is released.

@DayS, correct me if I'm wrong.

[dodgex]

Thank you for your fast reply. I already guessed that @DayS is the only official contributer at the moment.

from the release notes i got the following numbers

2.0   -> 2.0.1 ~  3 days  with  1 change
2.0.1 -> 2.0.2 ~  4 days  with  1 change
2.1   -> 2.1.1 ~ 11 days  with  2 changes 
2.1.1 -> 2.1.2 ~  9 days  with  1 change
2.5   -> 2.5.1 ~  4 days  with  1 change
2.7   -> 2.7.1 ~  5 month with  4 changes (extreme case?!)
3.0   -> 3.0.1 ~ 16 days  with 10 changes

i wonder if it would be possible to change the way how PRs get into a release. it looks you do something like the git flow concept. but with develop changes keeping small to be prepared for a 3.0.x release and keeping all upcoming features in branches/PRs.
what about bumping develop to the next minor release (in this case 3.1) containing completed features and if for some reason there is a 3.0.x required branch from master and backport the required changes from develop (like the hotfix stuff in git flow).
so it should be possible to do a patch level release but have the changes in minor availabe for the contributors without the need to have a self build release.

with a look on the numbers above i even belive that there werent that much changes on develop after a release that the patch level update might even be possible right from devlop (only exception the 2.7->2.7.1 step but i think this was due to 3.0 development).

that would result in an up to date 3.1-SNAPSHOT with latest features as soon as the changes are good to merge. this also reduces the maintenance on the PR itself like if PR 1 is ready but not merged and a month later someone starts PR 2 where stuff changed that is also changed in PR 1. now its time for a new release and PR 1 gets merged but that breaks PR 2 due to conflicts. with PR 1 merged as soon as its OK the month later started PR2 already has the PR1 changes and does not break anything.

i hope you understand what i try to say.

[WonderCsabo]

@dodgex I have good news, @yDelouis and i now have push access to this repository, so things may happen faster in the future.

[dodgex]

Congratulation! :)

Let's hope the best for AndroidAnnotations.

[yDelouis]

Thanks for the link about the git flow concept.
I think adding a release branch can be a good idea because it will help to release regularly. Indeed, now, we set a milestone to issues before having a correct PR. So, if anything goes wrong for this issue, we have to wait for it to be solved before releasing.
I think milestone should not be set to issues unless the PR is merged.
Then, priorities between issues should depend on the label (Defect > Enhancement > Contribution welcome, for example).

@DayS, what do you think ? Is it the way you handled released ?

[WonderCsabo]

Should we keep this open?

[dodgex]

@WonderCsabo I think that depends on how to handle this in the future.

The question is, how do you three plan to continue? keeping PRs open until there is enough for a 3.2 or do it like in the last few weeks, merging when a change is ready for prime time.

as i suggested, i would go the merge when ready way and actually target a 3.2 release. for the unexpected need of having a 3.1.1 that fixes some 3.1 bugs without adding new features one should take the 3.1 tag or the master branch (which seems to be in an unclean state compared to develop This branch is 19 commits ahead, 5 commits behind develop - i think it should NEVER be any commit ahead of the develop branch) and apply required fixes for a release. and as the numbers form my previous comment show this should be a rare case. and if you wait like 1 week (no longer) after a new minor release to see if there is the need to a patch level release there should be no issue at all.

sightly off topic:
as mentioned in my first post, i was using a custom snapshot since Oct 6. and this still continues as i'm using the @ReceiverAction annotation. :D

[yDelouis]

We changed a bit how we handle PRs. We still put milestone on issues to set priorities between issues but we are now merging PRs when they are ready and reviewed (even if the issue has been set to a later milestone).
And we will try to release a new version every month with the PRs merged between. So I hope you will have to wait only one month to get rid of your custom build of AA. ;)

[dodgex]

@yDelouis I like to hear that. :)

So I hope you will have to wait only one month to get rid of your custom build of AA. ;)

We will see what the future brings. 👍

i think we can close this issue for now.

[WonderCsabo]

the 3.1 tag or the master branch (which seems to be in an unclean state compared to develop This branch is 19 commits ahead, 5 commits behind develop - i think it should NEVER be any commit ahead of the develop branch)

This is the diff between master and develop. As you can see, only tag merge commits are on that, and some stale old commits. But i agree with you that master should be simply before dev. @yDelouis @DayS ?

[dodgex]

@WonderCsabo an ideal state in my point of view (and how we have it in my company) would be

branch	content
latest tag	the source of what got published as (in this case) 3.1 to maven central
master	latest tag (again 3.1 in this case)
develop	master + s/3.1/3.2-SNAPSHOT/ + everything else that got changed after the last release

[WonderCsabo]

I absolutely agree with you. Nice table btw.

[WonderCsabo]

@yDelouis @DayS i think we should resolve this branching issue. WDYT?

[dodgex]

any idea when merging stuff for 3.2 starts? ;)

if the plan to drop a new release every month is still present, stuff should get some time to be tested by snapshot users.

[yDelouis]

I will have some time this week-end to work on AA. I hope I will be able to merge some PR.

[WonderCsabo]

We already have PRs ready, but i do not want to touch the repo until the branching issue is not resolved.

[dodgex]

We already have PRs ready, [...]

that's why i asked ;)

[...], but i do not want to touch the repo until the branching issue is not resolved.

@WonderCsabo i know. thats why i added a PR that should fix the issue between master and develop.

to avoid this in the future @DayS (or whoever builds the next release) should not merge the release/3.x branch into master and develop seperatly but first into master and then master into develop.

maybe it is worth checking the Maven JGit-Flow Plugin for releases as it does the branching, merging and tagging stuff for you.

[DayS]

Hi,

Sorry I'm coming a bit late in this thread :)
It may be good to use release branches as suggested in the git flow concept. It'll be a bit heavier to handle PRs as we'll have to merge them back to develop but it allows us to release proper version.

[dodgex]

@DayS not sure if i did misunderstood you but there is nothing heavier than now. it seems you actually do the most of git flow already.

the work continues to stay on develop. so PRs(like feature branches in git flow) will merge into develop.

as soon as you decide to do a new release you create a release/3.2 branch from develop. there you bump versions (3.2-SNAPSHOT to 3.2) and run the maven build etc. as soon everything is done, you merge the release branch into master and after that you create the tag(androidannotations-3.2) from master
also merge the release branch back into develop and there you bump to next snapshot (3.2 to 3.3-SNAPSHOT)

and if you want, you could take a look at the maven jgitflow plugin linked above. this does the git related stuff for you.

[dodgex]

it happened again. https://github.com/excilys/androidannotations/compare/master

[WonderCsabo]

Thanks for noting that! We are aware of this and had a discussion with @DayS. Actually only the tag commit what are on master and not on dev. This is done intentionally by the maven release plugin. If you check out the git flow concept image, it also adds tag commits only to master.
I am not saying that it is better then just simply using a dev which is clearly ahead master - it is another concept. Both can be good, but we should decide what concept we are following.

[dodgex]

not sure how the maven release plugin is configured, but we use it at work too and i'm pretty sure that we don't have any commits on master that are not on develop. i'll check tomorrow.

[WonderCsabo]

Thanks. Here are the instructions how we release currently.

[dodgex]

Damn. You are true. So the merge release is ok! Sorry.

But i see you have to do all the git work by hand. There is a jgit-flow plugin from atlassian that is a replacement for the maven release plugin.

our workflow is like (copied from a jenkins job):

<pre> mvn -B jgitflow:release-start
<pre> mvn -B build-helper:parse-version versions:set versions:commit
<build> mvn clean install -Pproduction
<post> mvn-B jgitflow:release-finish -Djgitflow.pushReleases=true -Djgitflow.noReleaseBuild=true

iirc the second pre-step with build-helper and versions can be dropped as the jgit-flow plugin can update versions too. to bad that i can't remember the reason why it is there (I'm not the one who set up the our maven parent-pom).

the steps:
jgitflow:release-start: create release branch, bump versions
build: do what ever you have to do to build
jgitflow:release-finish: merge the release branch with master and develop, and taggig

[WonderCsabo]

Thanks. Actually i think @DayS already considered switching to this plugin, but we did not have time to try it. Does it produce the same behavior (e.g. the tag commit only on master)?

[dodgex]

Yeah.

Here is a graph of the result.

[WonderCsabo]

I think this is different than our current setup. I see no tag commits here. Master and develop differs because a new merge commit created for each.

[dodgex]

what is a tag commit? do you mean the Merge tag 'androidannotations-3.2' ?

that is here the 3rd line Merge branch 'release/1.1/17'

our flow:

• branch develop -> release/x.y
• update poms for release -> commit to release/x.y
• tag on release/x.y
• merge release/x.y -> master
• merge release/x.y -> develop
• update poms for next dev version -> commit to develop

your flow:

• branch develop -> release/x.y
• update poms for release -> commit to release/x.y
• tag on release/x.y
• merge tag/x.y -> master
• merge release/x.y -> develop
• update poms for next dev version -> commit to develop

here the release part for aa

and to have them together for easier comparision ours again: