Sanel Zukan wrote:
> 5. Start 'new' 2.0 with 1.1.x base and move current one in fltk-nuke branch.
>
> I was assuming this will be discussed on dev. group :) I am really glad
> Matt initiated this discussion since it was really needed.
Yes..!
> As Michael, Mathias, Greg and others noted, there are bunch of
> applications with varying range of complexity based on 1.1.x code. Even
> if is prevailed that 2.0 is now official next version, it is impossible to
> create 'compatible' layer; code is too much different. From this solution
> only freshly started projects will benefit, others will have to use
> either old version or maintain their own branch.
Yep, agree..
> > 1. continue separate development of FLTK1 and FLTK2
>
> Stronly against this. It is much better to focus all manpower to one
> than to split between them. With this, release cycle will be much faster.
The recommendation to drop fltk 1.x creates a situation that
kinda alienates (I'm guessing here) 90% of its current user base,
myself included, which would have nowhere else to go when fixes
are needed, other than to wait for 2.x to stabilize.
This is more than just frustrating to the 1.x folks; it pretty
much obsoletes our code investments. We have no where else to go
until fltk2 is ready, and it's unknown how long that will take.
If that's the case, then we have to have this discussion..
(kids, you may want to cover your eyes.. here comes the 'f' word)
If 1.x is discontinued, I perceive there's enough momentum
to cause.. a code fork.. (there I said it) that would last at least
until 2.x stabilizes to the point where it simply obsoletes the
1.x branch, and the 1.x folks can jump over to a stable 2.
I think most app devs can't maintain fltk themselves beyond freezing
a copy. And those that can implement fixes, it's surely a better
investment if they pool their efforts together in a public svn,
similar to what Okzid currently has on berlios.de; he's added
me to svn, though I haven't checked anything in yet, kinda waiting
to see what happens here.
My envisioning of 1.x is similar to Matt's; take the current
1.1.8 and continue it's maintenance to a 1.1.x, during which time
fixes can continue to be applied while an attempt is made to merge
in okzid's 1.1.6-utf8, creating a 1.2. Possibly even bringing over
other ABI breaking features that have to date been held back.
If forked, there'd probably be some freedom to not worry about
the ABI, since the OS distros will probably lock off their .so's
with 1.1.8 as the last 'official' release. (Real Programmers
release binaries with fltk statically linked anyway ;)
If that's the direction to go, is the best thing to a) leave fltk 1.x
up on the current svn, and open it up to folks who would be willing
to continue to maintain it, freeing up the current core folks for 2,
or b) relocate it as a completely separate project elsewhere?
Thing is, I might be wrong on my perception of the amount of code
inertia for 1.x; I can't tell if there's a silent majority here,
or if me, Matt and Ian and a few others are the only ones that see
1.x continuing beyond 1.1.8. I'm guessing the former. Also, it's
also Memorial Day weekend in the US, so most folks have been out
BBQ'ing burgers and dogs this weekend, which is what I'm about to do
in a few minutes..
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
