On 07/07/06, Jon A. Cruz <jon@...18...> wrote:
On Jul 6, 2006, at 5:08 AM, Ben Fowler wrote: Jon, I'm sorry that I missed this when you originally posted in this thread, you are of course 100% correct, unfortunately so is every other comment: I don't see a single path forward that will work for everyone, and we are probably left with Bryce's original proposal that the time has come to move on regardless of 'pain'.
Unfortunately this "pain" in this instance is not just a minor scratch, but the amputation of a few major limbs.
:-)
We're at 2.4 now. By jumping to 2.8 and past 2.6 we lose the support that has allowed me to develop on the Mac.
Oh.
The equivalent would be to that of being on Ubuntu or Debian and dropping all use of the stock tools like apt, dpkg, etc., and pulling down source tarballs for everything, including all the way to X11 itself. (and not in the nice Gentoo way either).
I agree with that assessment, but to try be balanced, surely this was the fallback position when we started with fink in the first place? It is not much different from what the fink folk do, though they have a wider audience.
Maybe this is overstating the case, but it seems to me that we cannot be like Peter Pan and stay at 2.4 for ever. Whilst there is a very good case for FLOSS projects in general minimising their requirements (for the benefit of developers and to widen the constituency of users), surely Inkscape does need to be nearly current. Why else would tool-makers want to upgrade their products?
I guess one factor for the other major platforms being left behind is what timeframe we're looking at (remember, at least one of the major distros isn't scheduling a release with 2.8+ support before December). If it's over six months out before we do a 0.45 release, then that is more reasonable. If we are targeting a shorter release cycle though, the move would be a lot more questionable.
I agree with that as well, but I would suggest that in practice there is a powerful argument to reject it, namely that planning too far forward and requiring big jumps from developers is not good in the FLOSS world (where low-level irritation even if prolonged, is far less damaging) though it is O.K. in the commercial sector, where investment in training, tools or process now can be offset against later benefits. We ought to minimise the investment of time and energy that a dev needs to put in, now, in order to do what he or she has ideas for. (Also, those later benefits do not always materialise).
Yes, it would be an excellent plan to hold off moving up from 2.4 for just one more release, yes it would be an excellent plan to hold off moving up from 2,4 until we could go in one jump to 2.10: I just don't see this as a good way to direct a FLOSS project, and I could not honestly argue for those tactics particularly for the convenience of one set of devs.
Aside from the other issues, has anyone listed out what it is that we need in 2.8+ that's not in 2.4 and 2.6?
That's a good idea, we would end up with more detail that just "it's time to move on", but I am sure that there a good list of what people would like, and would use if available.
Also, there might be circumstances where some distros do not have libs or versions that we expect. There seem to be many distros springing up at the moment, and there seem to be one or two that are specifically aimed at graphic artists - we can't expect every specialist distro builder to know everything about all our dynamic libraries. I still think that only viable policy for everyone, and the one that would encourage devs to come aboard is the positive one of moving forward according to our needs and the negative one of not holding back for the sake of a few of the slower ships in this convoy.
Since the sources are published there is no legal or effective barrier to anyone wanting to create a private branch that would match down-rated libraries.
Are you on Tiger or Panther, and if Tiger, are you using PPC or Intel? We could put libraries into svn so that devs did not have build them, if this could be made a simple process. Obviously this would not do for release versions, but that is probably not an issue anyway.
Ben