Re: [fluid-dev] Re: The 1.1.0 milestone

[David Henningsson]

Bernat Arlandis i Mañó skrev:
> Right now it's fully functional and equivalent to 1.0.9, I didn't want
> to loose any functionality and it hasn't, but it has broken API
> compatibility.

I think a wrapper (as jimmy suggested) is an almost must-have. I don't
know how much incompatibilities there will be, but we have 10-30
projects depending on us, so if we don't, my guess is at least half of
them will stay with 1.x.

> I decided to go by myself since there wasn't any active contributors
> interested and it was a bit hard for me to explain in detail what I was
> going to do in advance. I think is still hard to work together in the
> direction I've taken without talking a lot, but there's many things that
> can be done still in the stable branch in parallel.

So, how do you (and the others on this list) think we should proceed now
that there are active contributors interested?

Let's sum up some possible ways:

1) The 2.0 is merged with current 1.0.9 asap and then we all make an
1.1.0 (i e with no API changes that are not backwards compatible).
Requires somebody to write wrappers for the parts already API broken.

2) We never make a 1.1.0 and we all start working with 2.0 instead.
Requires lots of talking and work. And preferrably a release date/plan?

3) We continue to work in parallell with 1.1.0 and 2.0, with new
features in 1.1.0, means double-work and hard merging.

4) We continue to work in parallell with 1.1.0 and 2.0, with almost no
new features in 1.1.0, means 1.1.0 will be restrained "hey, you can't
touch this".

>> > Being one of the people "jumping in", I don't know much about Miguel's
>> > fork/branch or the 2.0 branch. That's why I asked for some pointers, so
>> > I don't have to read an entire year of messages. What I'm looking for
>> > the answer to is why all of you decided to branch instead of doing code
>> > cleanup one piece at a time, into the stable branch. I'm sure you had
>> > good reasons for doing so, I just don't see them.
> The main problem was breaking API compatibility and other
> quality/stability issues that might be important for a stable branch.

Okay.

>> - Timing related issues and faster than realtime audio rendering (#1,
>> #24, #15)
> This will have a different approach in 2.0, although ideas on this area
> and test cases for known issues would be useful.

What are your plans? You never commented on my "timing revisited" mail,
I think it sounds a bit like the "timing" component in the wiki's graph.

> I don't mean to be an obstacle for new development, so if this sound too
> restrictive for the new programming forces we should decide whether we
> hold to the old 2.0 plan or refrain from it and start another one. You
> should understand that doing long-term work on a project that might
> shift direction anytime isn't pleasant.

I understand that, but if we're going to reconsider that decision, it's
also important to know is how long-term the 2.0 branch actually is. How
long until a stable release? Six months? A year? Two years? What are
your thoughts about that?

// David