0.2 branch

[david.c...@laposte.net]

Hi,

I will fix this two pull requests (https://github.com/JanusGraph/janusgraph/issues/653, https://github.com/JanusGraph/janusgraph/issues/661) for the next 0.2.1.

So I will create 0.2 branch.

But I have to create two differents pull request for each issue (one for 0.2 branch and one for master branch) or just one for 0.2 branch and we will merge 0.2 branch into master when 0.2.1 will be released ?

David

[Jason Plurad]

Thanks for bringing this up, David.

I think we need to have a discussion on branching and release strategy first. For example, we have a 0.1 branch, but it's not clear to me whether we'll ever do another release from it. We needed the 0.1.1 release because of a significant migration issue in 0.1.0. I'd also note that 0.2.0 is suitable starting point for those still migrating from Titan 1.0.0.

Would we have a 0.2.1 release and what would make that different than 0.3.0? Or should we push people to 0.3.0? I'd rather not maintain extra branches if there isn't a strong reason or consensus to do so, so my preference at the moment would be 0.3.0/master only. I'm interested in hearing what others think.

[david.c...@laposte.net]

For me as 0.3.0 will depend on 3.3.x tinkerpop, we may need a 0.2.1 release to fix bug (only issue tags like bug).

[Misha Brukman]

On Thu, Oct 26, 2017 at 7:05 AM, Jason Plurad <plu...@gmail.com> wrote:

Thanks for bringing this up, David.

I think we need to have a discussion on branching and release strategy first. For example, we have a 0.1 branch, but it's not clear to me whether we'll ever do another release from it. We needed the 0.1.1 release because of a significant migration issue in 0.1.0. I'd also note that 0.2.0 is suitable starting point for those still migrating from Titan 1.0.0.

If there's a bug preventing a user from using 0.2.0, our options are 0.2.1 (sooner) or 0.3.0 (later, given the history of 0.1.0 and 0.2.0 release timelines). Given that 0.3.0 may have a number of other non-trivial changes, dependency upgrades, etc., it's possible that it, too, will ship with unknown bugs, and once they are discovered, we will then be back to the same question: 0.3.1 vs. 0.4.0, which will make user adoption more difficult.

Note that I'm not suggesting we should automatically create a branch for every major or minor release; just when we see a bug that should be fixed soon, and we agree it warrants a quick fix to unblock users or unblock adoption. If 0.3.0 comes with no bugs and no 0.3 branch is needed before 0.4.0, that's great!

 

Would we have a 0.2.1 release and what would make that different than 0.3.0? Or should we push people to 0.3.0? I'd rather not maintain extra branches if there isn't a strong reason or consensus to do so, so my preference at the moment would be 0.3.0/master only. I'm interested in hearing what others think.

What's the cost of maintaining a branch? If we agree that branches are for patch releases (e.g., bug fixes), they should get very few PRs. E.g., how much effort was spent maintaining the 0.1 branch?

[Jerry He]

I agree that we should probably keep the option of having bug fix release on 0.2.x branch open. We may get critical bugs reported.

IMO only important/critical/blocking  bugs should be considered to 0.2.x.  Then if we see there is a need for a release, we will do it.

There is also a role of a 'branch manager', which can normally be the same person as 'release manager' on the branch. 

'branch manager' is the coordinator for the branch, and can accept or deny a backport to the branch, and then call another release if needed.

Thanks.

[Jason Plurad]

With 250+ dependencies, it's pretty safe to say there's always at least 1 bug lurking in the code in every branch. Jerry's idea of a 'branch manager' sounds interesting. We'd need a volunteer for each branch (0.1, 0.2, master).

My main concern is around maintenance of multiple branches. We had some issues several months ago where some fixes were put into the 0.1 branch but not into master. If it's possible to reduce the energy required to get fixes merged into multiple streams (both for the contributor and the committer), that would be most helpful. It's also important to think about how long we plan to maintain and when to retire those branches.

[Robert Dale]

Looks like the missing jars issue is a great first candidate for the 0.2 branch ;-)

https://github.com/JanusGraph/janusgraph/issues/674

Robert Dale

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/5d0ace9e-c258-4b09-93df-b0d8df2a4e90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jerry He]

We don't have a 0.2 branch yet. (I don't see one).

Should we branch off?

Thanks,

Robert Dale

To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.

[Jason Plurad]

Created: https://github.com/JanusGraph/janusgraph/commits/0.2 Please check the diff to make sure it's correct.

[Jerry He]

Thanks, Jason. 

It looks good.