Le 03/12/2017 à 03:37, Rene Rivera via Boost a écrit :

On Sat, Dec 2, 2017 at 6:33 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:

...

...

I'm looking forward to hearing other people's thoughts on the matter. Boost.Hana2

That was a joke, right?

Why? Vicente

On Sun, Dec 3, 2017 at 6:07 AM, Niall Douglas via Boost < boost@lists.boost.org> wrote:

On 03/12/2017 02:37, Rene Rivera via Boost wrote:

...

On Sat, Dec 2, 2017 at 6:33 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:

...

...

I'm looking forward to hearing other people's thoughts on the matter.

Boost.Hana2

That was a joke, right?

Louis said:

...

this would be a large breaking change, with all kinds of API changes

That's obviously a Boost.Hana2. No joke. Not sure why you thought that.

Because if it's a big enough change to require a new library module.. It should also require an entirely new name.. And an entirely new review. I.e. if it's different enough it's no longer Hana. It might solve the same domain but it will do it in a different manner. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

"Paul A. Bristow via Boost" wrote in message news:011601d36d29$39719c70$ac54d550$@hetp.u-net.com...

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Niall Douglas via Boost Sent: 03 December 2017 01:33 To: boost@lists.boost.org Cc: Niall Douglas Subject: Re: [boost] Policy for breaking changes

...

I'm looking forward to hearing other people's thoughts on the matter.

Boost.Hana2

+1

+1 We have already Boost.Coroutine and Boost.Coroutine2 and Boost.Signals and Boost.Signals2 (Boost.Coroutine and Boost.Signals are now deprecated). There was also a breaking change in Boost.Coroutine between 1.54.0 and 1.55.0 which I found annoying (the change was documented in the release notes; I would prefer upgrading though without breaking code - possible now thanks to Boost.Coroutine2). Boris

Degski wrote:

The best thing would indeed be to stick to c++98 and be done with it... All this new stuff (what *are* they thinking?), it's a pita and you actually have to try and master it (and that takes effort), so bullocks...

Bah! Who needs these newfangled automated weaving looms anyway? :) On 4 December 2017 at 23:19, degski via Boost wrote:

On 4 December 2017 at 15:44, Boris Schäling via Boost < boost@lists.boost.org

...

wrote:

...

I would prefer upgrading though without breaking code - possible now thanks to Boost.Coroutine2).

The best thing would indeed be to stick to c++98 and be done with it... All this new stuff (what *are* they thinking?), it's a pita and you actually have to try and master it (and that takes effort), so bullocks...

degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

"Paul A. Bristow via Boost" wrote in message news:011601d36d29$39719c70$ac54d550$@hetp.u-net.com...

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Niall Douglas via Boost Sent: 03 December 2017 01:33 To: boost@lists.boost.org Cc: Niall Douglas Subject: Re: [boost] Policy for breaking changes

...

I'm looking forward to hearing other people's thoughts on the matter.

Boost.Hana2

+1

+1 We have already Boost.Coroutine and Boost.Coroutine2 and Boost.Signals and Boost.Signals2 (Boost.Coroutine and Boost.Signals are now deprecated). There was also a breaking change in Boost.Coroutine between 1.54.0 and 1.55.0 which I found annoying (the change was documented in the release notes; I would prefer upgrading though without breaking code - possible now thanks to Boost.Coroutine2). Boris

On 12/03/2017 02:18 AM, Vicente J. Botet Escriba via Boost wrote:

Le 02/12/2017 à 22:44, Louis Dionne via Boost a écrit :

...

Hi all,

So far, I've been careful about not doing any breaking changes to Hana. Hana obeys semantic versioning, and I'm accumulating desirable breaking changes until I'm ready to publish a new major version.

I'm wondering what's the policy for major breaking changes with Boost libraries. For example, let's say I wanted to do an update of Hana with C++17 features; this would be a large breaking change, with all kinds of API changes, etc..

- Are such drastic changes prohibited altogether? Or perhaps they’re not    prohibited but there’s historical evidence showing it’s always a bad    idea? - Do such changes require going through a mini review? - Is it customary to leave the old version of the library there in a    separate directory (or put the new one in a separate directory)?    I think Spirit does that, e.g. Spirit Classic is still available IIRC.

I think I know the answer to these questions from observing other author's behavior, but I'd like to see what the community thinks about this. It has an impact on the Boost libraries as a whole, since a major breaking change in one library could prevent users from updating Boost as a whole, which has an impact on all of us.

I'm looking forward to hearing other people's thoughts on the matter.

Hi Louis,

do you want to break the users code with your changes? I don't believe, you could want it.

do you want to maintain two versions of your library?

If yes, do you want to require that all the parts of an application uses the same library version? I suggest to don't do that, you will lost users.

If you want to make it possible to have two version of Boost.Hana, I believe the best is to take a new folder and a new namespace, as Boost.Spirit.

I've not do that. I did a really bad work with Boost.Thread/Chrono and I'm paying for it.

Spirit did something like that. It has an x3 version and a qi version of it's code. The x3 version is used with: #include I don't know how well that went. One thing to guard against is to make sure you don't duplicate #include guards. Spirit x3 didn't and that led to minor problems when trying to use the qi as well as the x3 versions of code :( -regards, Larry

If possible can people attempt to remove [SPAM] from Subject: lines before replying? (I think, looking at the thread history, that this may have been added by Louis Dionne's email provider, but however it occurred the consequence is my inbox (and possibly that of others) doesn't get these messages without manual intervention.) Thanks, Roger.

On 12/03/17 20:13, Rene Rivera via Boost wrote:

On Sun, Dec 3, 2017 at 9:51 AM, Robert Ramey via Boost < boost@lists.boost.org> wrote:

...

Finally, I see hana as very niche library which is not in wide usage in user code. So it's not clear how many people would be effected by "breaking" changes. If it were 10 people I'd say we should just let the author deal with it. If it's 100,000 people, it should be handled differently. Unfortunately, we have absolutely no useful information regarding how widely any particular library is actually being used. It would be useful to have such information for cases like this as well as for many others.

Some information from the Conan Hana package.. < https://bintray.com/bincrafters/public-conan/Boost.Hana%3Abincrafters#statis...

...

.

Is it supposed to show some kind of graph? I don't see any.

On 3 December 2017 at 21:00, Rene Rivera via Boost wrote:

Yes, it's supposed to show a graph, that indicates there where 7 downloads in the last month. Works for me with Chrome.

Most of boost depends on config, and there were only 441 downloads of it. That's a very small sample of boost downloads, and I suspect it's skewed towards binary packages.

On 12/3/17 2:02 PM, Rene Rivera via Boost wrote:

On Sun, Dec 3, 2017 at 2:42 PM, Daniel James via Boost < boost@lists.boost.org> wrote:

...

On 3 December 2017 at 21:00, Rene Rivera via Boost wrote:

...

Yes, it's supposed to show a graph, that indicates there where 7

downloads

...

in the last month. Works for me with Chrome.

Most of boost depends on config, and there were only 441 downloads of it. That's a very small sample of boost downloads, and I suspect it's skewed towards binary packages.

Yes, it's a small sample. As it's limited to people who are using conan to obtain the modular Boost. But's it's better than no samples :-)

Let's try to agree that it would be useful to have better information on the usage is of various C++ libraries - not restricted to Boost. Robert Ramey

On 12/04/17 06:10, Louis Dionne via Boost wrote:

...

Hi all,

So far, I've been careful about not doing any breaking changes to Hana. Hana obeys semantic versioning, and I'm accumulating desirable breaking changes until I'm ready to publish a new major version.

I'm wondering what's the policy for major breaking changes with Boost libraries. For example, let's say I wanted to do an update of Hana with C++17 features; this would be a large breaking change, with all kinds of API changes, etc.. [...]

Thanks everyone for the feedback, it's quite useful and it crystallizes some of the expected behavior for Boost authors. Here's a summary of what I got away from the answers:

1. Non-breaking changes can be done without restriction. 2. Small breaking changes can be made, but users should be given notice a few releases before the change is published. 3. For large breaking changes WITH a migration path from before-the-change to after-the-change (e.g. filesystem v2 -> v3), the change should be made by providing the functionality in a separate directory/namespace, and users should be given a few releases to move over. The before-the-change functionality can be removed after some time. 4. For large breaking changes WITHOUT a migration path (e.g. spirit 2 -> 3), the change should be made in a separate directory/namespace, and the before-the-change state should be preserved (because there's no migration path). 5. If a large change falling into categories (3) or (4) is equivalent to a redesign or rewrite of the library, this should be treated as a new library and a formal review (or at least a mini review) is encouraged.

Please correct me if I got something wrong. Would it be useful to document this officially somewhere on the Boost website? Is it desirable for Boost to adopt some kind of "official stance" on this matter (for now none of this is normative)? I can submit a PR to add the documentation if I only know what module I must submit it to.

As far as Hana is concerned, I think the logical thing for me to do is to proceed by way of small breaking changes with a deprecation period, at least for the time being.

I think, this is ok, but only as long as the affected functionality of the library will be still usable in C++14, i.e. C++17 features are completely optional.

"Best practice for breaking changes"

1. Name your library "hana14" instead of just "hana". :-) Also, 2. Semantic versioning is useless in the Boost context. :-)