Date
1 - 3 of 3
[DISCUSS] JanusGraph 0.2.2 release
Jason Plurad <plu...@...>
I created a milestone for the 0.2.2 shortly before 0.2.1 was released. The 0.2 branch is open and the versions are updated to 0.2.2-SNAPSHOT. These are the open PRs that require review/approvals. A couple discussion points: 1. I put a tentative date on it for September 15, 2018, setting it roughly 2 months apart from the 0.2.1 release. The goal would be to have any content targeted for that release to be merged by that date. Anything that wasn't merged would be moved out to the next milestone. We could move the date around a bit in case a high severity fix is identified, but I think a goal of a maintenance release every 2 months would be a reasonable pace. 2. How long should we continue to maintain the 0.2 branch? We haven't yet made it to 1.0 and we have the real possibility of maintaining 3 development branches soon: 0.2, 0.3, and master. Right now, 0.2 supports TinkerPop 3.2.x while 0.3 supports TinkerPop 3.3.x. Note that we haven't created the 0.3 branch yet since there are no new features that would require separating it from master yet. Depending on the TinkerPop 3.4 release (currently targeted for end of summer 2018), master branch would support that release. My opinion is that we should maintain support for only the 2 most current versions of TinkerPop. I might even argue to only support the latest TinkerPop version, but perhaps there are production JanusGraph users out there that might prefer a bit more stability. Thoughts? |
|
Jerry He <jerr...@...>
I agree that maintaining 3 development branches will be tough for us. Ideally we should avoid it at this stage of the project. I am for a last release of 0.2.2 as Jason plans it. (The three PRs don't seem to warrant a release on the other hand.) The active branches will be 0.3 and master, with fixes targeted to 0.3 branch and any major changes/upgrades going into master. Thanks, Jerry On Tuesday, August 7, 2018 at 7:36:52 PM UTC-7, Jason Plurad wrote:
|
|
Jason Plurad <plu...@...>
With maintenance releases, I don't think a minimum number of PRs merged should be a requirement. The goal is to fix bugs that are affecting that branch and provide an easy way for consumers to adopt it easily without having to worry about dependency changes or other migration headaches. On Thursday, August 9, 2018 at 1:02:53 AM UTC-4, Jerry He wrote:
|
|