> From: [email protected]
> Date: Tue, 23 Aug 2011 12:16:40 +0200
> To: [email protected]
> Subject: Re: [fltk.development] Funny build warning in VisualC 6 / FLTK 3core
>
>
> On 23.08.2011, at 11:59, Ben Stott wrote:
>
> > > > Side note: I don't like the "fltk3" naming convention anyway.
> > > > Some day in the future we will have fltk4 and fltk5, maybe - my
> > > > favourite naming would be that the newest and best FLTK version would
> > > > always be "fltk", but I know that this would conflict with FLTK2
> > > > compatibility, and so we *had* to choose "fltk3" for now. :-(
> > >
> > > Sigh. Yes. Let's just assume for now that the jump from FLTK3 to FLTK4
> > > will be so huge, that we will later be glad we did it this way :*)
> >
> > I have to say I agree with Albrecht; it's probably best that the most
> > up-to-date (or current-heavy-development?) version has the FLTK tag, and
> > the older versions take the FLTK<version_number> tag.
> > I'm happy to convert all the fltk2 stuff to the "fltk2" naming convention
> > to make this easier for you. I'm also happy to wear all the flak from the
> > current set of 2.0 users over this change (if it's something you'd prefer
> > for fltk3)!
> > If we do decide to give 3.0 the "fltk" tag and fltk2 the "fltk2" tag, we
> > can always just invoke the fact that 2.0 is still alpha (and thus such huge
> > changes aren't completely a Bad Thing ;-)
>
> I appreciate the offer! Maybe we will actually get to that.
>
> I do have concerns though: in the real world, someone will download some
> source code and type 'make'. Now, if the app was developed with FLTK5 when it
> was the newest and greatest, and all the naming is fltk::, but now FLTK7 is
> the top of the line, he will likely receive hundreds of compiler errors,
> because we simply can not keep source code compatibility forever.
>
> I already had tons of "fun" until I found out that fluid1 was found earlier
> in the path than fluid3 which I just built, leading to corrupted .cxx and .h
> files.
>
> And there is always the line:
>
> using namespace Fl = fltk3; // I am used to FLTK 1
>
> or
>
> using namespace fltk = fltk3; // I am used to FLTK 2
>
> What do you think?
On the one hand, I think your point is fair enough; compiling old code has the
potential to break and aiming for compatibility between releases (or at least
not breaking *old* releases) is a good idea. By the same token, however, this
would either a) force developers to release FLTK source code with their program
code if they intend to never maintain it again, or b) use the newer versions of
FLTK for maintained code, thus reaping the benefits of bug fixes, etc.
I'm all for the renaming, in honesty. I hate seeing code "in the wild" with
libraries that have long progressed from the point they were written. If it's
"in the wild" it needs to be maintained or not there at all, IMO. This way
users benefit from bug-fixes and enhancements to FLTK, or they don't use the
old app that could potentially give FLTK a bad name through bugs that have been
triaged, etc.
Plus, we really only need to take the tag from fltk2 at the "last minute"; once
FLTK3 is stable. The same could be done for future versions. This maintains
stability up until the very last day before release (and during testing can
always be aliased as you suggested, so those that intend to develop apps with
fltk3 can use the fltk:: namespace for their code with no hesitation).
I think no matter which way we go, we're going to run into a problem one way or
another. It's really just choosing what we decide is the lesser of the two
evils....
Regards,
Ben
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
