On Mon, 24 May 2010 11:05:26 +0200 Benjamin Zores <b...@geexbox.org> said:
> On Mon, May 24, 2010 at 10:57 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Mon, 24 May 2010 10:41:41 +0200 Benjamin Zores <b...@geexbox.org> said: > > > > simple answer: no. > > why? because until 1.0 we are NOT maintaining ABI or API compatibility. > > that's what 1.0 is about. no - we will NOT change the .so major version for > > this as i want to STRICTLY keep so versions in line with library versions. > > a 2.0 == api/abi break from 1.x but until 1.0 we discard any effort in > > tracking abi and api changes. this saves time and effort for us and this > > has been the policy ever since. (if we have changed .so major versions we'd > > probably be at like libXXX.so.87 by now). so not going to happen. as of 1.0 > > compatbility will be strictly adhered to. ie 1.0 and 1.1 will be forwards > > compatible (apps written for 1.0 will work with 1.1 - but possibly not the > > other way around - eg we added a function call in 1.1 that wasn't in 1.0 - > > this is the standard way things work on linux/unix). > > I do understand your reason fully and was expected such an answer actually :-) > Though I wasn't requesting for a major/minor version bump. > > Eg. Elementary 0.6.0.063 -> 0.6.0.064, the library still is called .so.0.6.0 > > Anyhow, I don't know since how long people are waiting for 1.0 but > you probably heard this complaint much more than I ever did :-) yup - i know... and it's some pain you'll have to live with.... sorry.. until 1.0 - but.. trust me - we are actively talking of doing a 1.0 alpha - that means we dont intend any abi/api breaks from there and plan to add some final small touches and clear up bugs. we're not quite there yet. i want to whack out some more todo items and get a bunch of patches in before calling that. the problem is - it's an api. once we lock it down - we are stuck supporting that version of the api for YEARS. i don't want to do that. i want to keep the warning signs up and keep those using them on their toes - so they know that "nup.. you cant rely on the api to be solid and 100% supported going forward until 1.0". thats kind the the seal of approval thing. until then i am keeping things fluid. right now i get to make a change if its needed - and dont even think about it. that saves pain and effort. we do need version check handling as of 1.0 - definitely. as i said - i've started adding it in. eet was the first candidate for a test as its actually at 1.2.3 now. 1.3.0 will have the version check in it (and that makes me really unhappy because it should have been in from 1.0 on and that just tells you eet was released way too soon - entirely because of pressure to do so and with nothing useful having ever come of it, and now simply more complexity for app developers as they had no way to know api version until 1.3 - i want that in from 1.0.). i've been doing libraries for linux for longer than most people have even known about linux. i've learned a thing or 2 along the way, and one of those is to be very conservative about versions, changes and releases, as once you have an api - and people use it, you're STUCK maintaining and supporting it. for MANY years. i do not want to be stuck with something that isnt at least half-way decent and thats going to stand the test of time. otherwise you will see a 2.0, 3.0, 4.0, 5.0 in quick succession and a bunch of very pissed off app developers who have to adapt (or stay on an old version) and for sanity mainline will simply not want to release patches, fixes etc. for 1.0 when we're on 4.0 ourselves. so don't think i hate you :) i am trying to maximise ultimate quality while minimising support etc. costs. there is a period of pain as a result :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
