I demand that I definitely did write...
[snip]
> The consensus (on #xine) is that we should do a [xine-lib] release now.
> Only one thing remains: who's going to do it?
Anybody?
If nobody says otherwise, I'll do the release at around 11pm (BST).
--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT.
I am Neelix of Borg. Your assimilation will boost the Collective's morale.

On Sun, 8 Apr 2007 11:53:21 -0300
"Miguel Freitas" <mfreitas@...> wrote:
> then i think it would be better as 1.2. remember that if we break ABI
> we will probably need to change the libtool numbering (like
> libxine.so.2.xxx or something) so old applications won't break.
I know, I did it already actually, and I did update the versioning to
1.1.99 so that also the plugins don't collide.
I'd actually would like to start tonight a xine-lib-1.2 branch merging
ffmpeg_integration (that seems to work fine by its own) with nopadding
(that also seems to work fine) to be less specific, and having a
starting point at least.
> in cases like this, do we also change the name of the package so users
> can have both versions installed (as a transition, before everything
> else is rebuild)? perhaps keeping the package name is fine since API
> didn't changed?
Well, I worked till two months ago in a distribution, so I can share my
point of view as a packager about this ;)
As long as the API isn't entirely broken, just breaking ABI (at a minor
version change.. where the versioning is MAJOR.MINOR.RELEASE, before
misunderstanding) should be fine, for non-critical libraries
(libexpat's soname change between 1.x and 2.x was annoying just because
you ended up having libexpat linked everywhere).
Removing obsolete functions/macros/whatever should also be fine, if
they were already obsoleted when 1.1 was released.
Changing soname also should allow most binary distributions to allow
having both libxine1 and libxine2 installed together (the -dev packages
likely would collide though, but that's beside the point).
I would actually like to do another thing that might be a bit more
annoying on the short run, but easy to fix for other projects: remove
xine-config and relying only on the pkg-config file, as that should
already provides everything strictly needed, and for what concerns
plugindir, it can just be added.
But that's not going to happen just yet, opening 1.2 branch will just
be the first step for now..
--=20
Diego "Flameeyes" Petten=C3=B2
http://farragut.flameeyes.is-a-geek.org/

Dear Xine Contributots,
I am really thankful to Free/Open Source Software development community for
their overwhelming response to the survey on practices and problems of
defect management in Free/Open Source Software projects.
The Online Questionnaire is available at:
http://anu.puchd.ac.in/phpESP/public/survey.php?name=FOSS_Defect_Survey
I hope you have found all the questions interesting and thought-provoking.
Your answers will be kept anonymous.The data thus collected will only be
used for research purpose. The insights gained from the study can further
help us to extract publicly accessible defect data and determine impact of
defect management practices on software quality. The results of study will
soon be communicated to you.If you have not participated ealier, you may
spend a few minutes now too.
Thank You
With regards,
Anu Gupta
Senior Lecturer
Department of Computer Science and Applications,
Panjab University, Chandigarh.
INDIA
In case of any problem in accessing/using the above mentioned link please
contact:
E-mail: anugupta@...
anugupta98@...