Should the 1.0-dev branch be the master branch?

[OlivierHnt]

As I dive deeper into the repository, I am going through open issues and PRs. I have noticed that quite a few are actually solved on 1.0-dev branch. For instance, it seems that #94, #229, #345, #416 and #464 are already fixed.
Also, after the PR #555 is merged (once the issue on Windows is resolved) then also #316 and #434 will be fixed.

I may be wrong here but wouldn't it be easier if the 1.0-dev branch becomes the master branch?
Not having the 1.0-dev branch the master branch makes it a little hard to track progress and know what still needs to be done/fixed. So contributing is a little harder than it could be.

Furthermore, the version 0.20 of IntervalArithmetic has received very little alterations in the past year and seems to be on maintenance mode (which would still be the case once the master branch is changed). As far I can tell looking at the history of the PRs, the next breaking release is expected to be based on 1.0-dev, no?

In fact, I would go even further in my reasoning: maybe the 1.0-dev branch ought to be tagged as the 0.21.0 version of IntervalArithmetic once it is deemed production ready.
That would allow all the changes to be tested in the wild and new features to be incorporated at a better pace (e.g. the entire flavour mechanism does not need to be finished for the 0.21.0 version and can be completed in 0.21.x). A plausible scenario would be to release 0.21.0 once the 1.0-dev branch is on a par with the current stable version 0.20.8. There are quite a few features I am eager to see incorporated in the library! 🙂

[Kolaru]

@lbenet and @lucaferranti chose to start the 1.0-dev branch they may have more to say about it.

Personally I don't mind either way. 1.0-dev can become master if it is not broken and tests pass. Our huge backlog of dangling PR is a problem we have to address at some point either way ^^'

[lbenet]

Our huge backlog of dangling PR is a problem we have to address at some point either way ^^'

I fully agree with Benoit.

The summary is more or less the following: development for the current release version (0.20.x) can continue (and hopefully be useful in the 1.0-dev branch); the bunch of PRs to master that solve tiny issues may be ported to 1.0-dev, with some extra work. In parallel, we continue developing the 1.0-dev branch, until we are really complying with the standard. Once we are ready to "merge" the 1.0-dev (it's unclear to me how to proceed in terms of git, if we actually have to overwrite or rename the branches), we should release v1.0 🍺 🎉

The advantage of this scheme, I think, is that it allows other packages that depend on IntervalArithmetic to adapt to the 1.0-dev release. Some time ago, I checked if IntervalRootFinding.jl using the 1.0-dev branch had problems, and it turned out that some tests were failing. I tried to solve those issues, but got distracted and forgot about it.

Once said all this, you are right, this scheme makes it harder to track progress...

Regarding tagging the 1.0-dev branch as 0.21.0 sounds ok, but maybe it is better to tag it as 1.0-dev.

[OlivierHnt]

development for the current release version (0.20.x) can continue (and hopefully be useful in the 1.0-dev branch); the bunch of PRs to master that solve tiny issues may be ported to 1.0-dev, with some extra work

I think it would help to focus on developing the branch that is most likely to become the 1.0 version. I think 1.0-dev branch and master branch have enough differences that backporting fixes won't be very straightforward. So then we would end up duplicating efforts while knowing that one of the two branch will be abandoned.

The advantage of this scheme, I think, is that it allows other packages that depend on IntervalArithmetic to adapt to the 1.0-dev release.

I think this is a little unusual, no? Isn't the standard way of checking out latest features of their dependencies done by tracking the master branch?
Currently the 1.0-dev branch is hidden among other existing branches.

Once said all this, you are right, this scheme makes it harder to track progress...

I guess the question is: is it clear that 1.0-dev is the branch that will eventually make it as the 1.0 release?
If so, I think it makes sense to have it as the master branch (specifically for contributing and clearing issues / PRs).
Also, this does not mean that we lose track of 0.20.x. I am not an expert with git commands, but from what I understand, one can make a new branch, called "release-0.20", out from the current master branch and use it for maintaining 0.20.x.

Regarding tagging the 1.0-dev branch as 0.21.0 sounds ok, but maybe it is better to tag it as 1.0-dev.

Since this would not follow the standard semantic versioning, wouldn't this be a little confusing?
Also, since 1.0-dev introduces a lot of new mechanics, I think it would be worth it to introduce it as the successor of 0.20.x (so 0.21.0) before hitting a 1.0 release. This would help package maintainers to play around with the new features and have an opportunity to give some feedback.

[OlivierHnt]

I'd like to revive this thread to discuss some concrete plan of action for IntervalArithmetic 🙂.

As I mentioned before, considering the amount of changes in the 1.0-dev branch I think it would be very useful to have it released as the 0.21.0 version.
The 1.0.0 objectives require a lot more work and time while there are already practical improvement contained in the 1.0-dev branch. Notably, there are issues that could be closed on 1.0-dev: #85, #94, #127, #182, #209, #229, #255, #316, #317, #319, #345, #346, #410, #416, #434, #464, #470, #474, #491, #495, #515. As well as #513 and #538 if the PR #562 is merged.

However, there are still some missing features that should be included prior to a 0.21.0 release. Perhaps we could pin the big items to be included in 1.0-dev which are not necessarily 1.0.0 objectives?
As a starting point, here are the main items on my laundry list:

• Bug in integer power of BigFloat interval #83
• interval + inf returns invalid interval #535
• fix some method ambiguities (e.g. see Use styles in broadcasting #278)
• improve support for complex intervals (e.g. see Broken functions for complex intervals #41)
• port PR [WIP / RFC] Configuration mechanism for directed rounding and fast powers #388 (e.g. see Make fast powers (pow) the default #14, Accelerate pow #18, Power ^ allocates #103, API for choosing power function #355)
• remove Markdown and EnumX as dependencies
• make symbols.jl a module and do not export it (e.g. see Don't export ∞ #270 and .. clashes with Makie)
• EDIT: clean up boolean functions of intervals; fix Interval comparisons may make other packages functions behave unexpectedly #165, < and > breaks interval? #566

As well as:

• clean up the test suite (here I do not mean to resolve ITF1788 compliance #465 which is a 1.0.0 objective). In particular, are IntervalContractors.jl and Polynomials.jl needed?
• overhaul the documentation

Any thoughts on this?

[Kolaru]

Considering the progress made, I think it is now reasonable to release v0.21.0. Further improvement can still be tagged later as v0.21.x, and we can still continue to update the earlier version in v0.20.x as well if really needed (I say really needed because I don't think we have the workforce to maintain 2 branches in parallel).

It is of course a very breaking change, but it has to open at some point, and I can't see a strong reason to keep 1.0-dev as a branch anymore (the hotfixes on master we envisioned at first didn't quite happened, and I think it is now too late).

I will make the PR 1.0-dev -> master this weekend (with the plan to merge it and potentially release v0.21.0 next week), unless there are strong opinions against it @lucaferranti @lbenet @dpsanders

From an organizational point of view, I think it would be nice to restart the triage call to try put some order in the issues and PR. That would help determining what should be in 1.0, what should/can come before, and what can be left around for longer. @OlivierHnt Would you be interested to join ? I'll try to set up the next call in about two weeks.

[lbenet]

Considering the progress made, I think it is now reasonable to release v0.21.0. Further improvement can still be tagged later as v0.21.x, and we can still continue to update the earlier version in v0.20.x as well if really needed (I say really needed because I don't think we have the workforce to maintain 2 branches in parallel).

Let's go for it! It is a way to put some weight on our shoulders and get it done! (I really like your really 😄 )

It is of course a very breaking change, but it has to open at some point, and I can't see a strong reason to keep 1.0-dev as a branch anymore (the hotfixes on master we envisioned at first didn't quite happened, and I think it is now too late).

I also have to agree... In addition, any PR left around could be either incorporated, updated or simply closed.

I will make the PR 1.0-dev -> master this weekend (with the plan to merge it and potentially release v0.21.0 next week), unless there are strong opinions against it @lucaferranti @lbenet @dpsanders

No objections on my side!

From an organizational point of view, I think it would be nice to restart the triage call to try put some order in the issues and PR. That would help determining what should be in 1.0, what should/can come before, and what can be left around for longer. @OlivierHnt Would you be interested to join ? I'll try to set up the next call in about two weeks.

I also agree.

As a side note, I've been playing with other packages that somehow use IntervalArithmetic. The change is indeed a breaking one.

[OlivierHnt]

From an organizational point of view, I think it would be nice to restart the triage call to try put some order in the issues and PR. That would help determining what should be in 1.0, what should/can come before, and what can be left around for longer. @OlivierHnt Would you be interested to join ? I'll try to set up the next call in about two weeks.

Yes that sounds great 🙂

[Kolaru]

@OlivierHnt How can I contact you privately to organize it ? Not that it would be secret, but I rather not just drop some zoom link publicly to begin with ^^'

Feel free to contact me via email or slack if you'd rather not have it publicly displayed.

[OlivierHnt]

@Kolaru, by the way, I sent you an email on the address displayed on your GitHub profile.