[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] Re: The 1.1.0 milestone
From: |
jimmy |
Subject: |
Re: [fluid-dev] Re: The 1.1.0 milestone |
Date: |
Sat, 18 Apr 2009 07:25:50 -0700 (PDT) |
> 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