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

[jimmy]

> Date: Thu, 16 Apr 2009 20:01:04 +0200
> From: David Henningsson <address@hidden>
> 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.


Although I name it as a possible thing to do, I do question the true cost of 
efforts being worthwhile thing to do.  Folks who want to use old features 
should just stick to 1.0.x code base.  I think for the price of progress, a 
migration is for the better.

Just think about how I was shackled to Windows because I continue to use and 
accepts MS Office file format.  Once I decided (several years back) that I will 
only create new files using Koffice, or OpenOffice file format, and convert any 
older files I need right away to the new format.  Also, any old files I don't 
need to access right away won't be converted until absolutely needed, this way 
I don't have to waste time converting files I may never need.  Suddenly, I am 
free as a bird.



> > 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.


Of course I don't speak for anyone but myself.  I'm just thinking aloud here.

It seems no one has really seen Bernat's new refactored code yet.  So it is not 
really clear if it makes good sense to make pre-judgement on how good or bad 
the new code base and new API may be.  I assume Bernat is more than willing to 
donate the code back to this community to bring uo the issue here.  It would be 
nice if we take at least a quick look at the code and see how it goes from 
there.  But so far, there's no interest in hosting the the refactored code 
package.  It may offend some folks, or may cause a riff if the code is posted 
elsewhere, so Bernat may be reluctant to do so, besides the added 
responsibilities of maintaining such code.

I guess Josh may be busy with so many projects and other things to do, he may 
not want to take this code and it falls on his plate as additional 
responsibility since it is hosted by this project.  Plus, this new code base is 
somewhat new and has different slant to how things are stuctured and fit 
together.

I could only suggest that Josh should go ahead and create a temporary branch, 
call it something unoffictial and obscure, like 0.0.8765 and anyone here who is 
interested could take a look.  This way each of us can decide if the new 
refactored code looks OK or not and decide what may be better.

I see the push for 1.1.0 in similar light of not wanting to apply and migrate 
such code diff's for every new release of FS.  At the same time, such new code 
diff's are so new that there is only one or two people using it.  So it is not 
too critical, so let us not rush to adopt such new features and having to 
maintain it along with any possible bugs or issues as part of 1.1.0.

Regardless, I think I would love to see new features added, including code 
refactoring.  Partly, because I have seen current (old) code that I have ceen 
cause FS to disappared (probably from invalid/null structure reference), which 
can cause jackd to trap and has to be restarted, too.  I don't keep track of 
it, but sometimes stoping, or pausing a really fast midi, or dragging a new 
midi and dropping it to kmid while it is playing a different midi file can 
cause such problem for FS.

Don't take things too personally, or be too offended, I don't mean to.  I think 
it is best to say what we think and we can work through our differences in 
preference, or assumptions that others may not understand.

Best regards,

Jimmy