[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-poppler
Subject:    Re: [poppler] Rethinking poppler releases
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2014-09-26 17:35:22
Message-ID: 2524463.y4q5C41LOf () xps
[Download RAW message or body]

El Divendres, 26 de setembre de 2014, a les 14:35:10, Carlos Garcia Campos va 
escriure:
> Albert Astals Cid <aacid@kde.org> writes:
> > Hi all, we released 0.26.0 five months ago. And we have no schedule for
> > 0.28.0 (or i can't find no email discussing it).
> > 
> > This is something that has been happening repeateadly, we "forget" when
> > the
> > next feature release or we need to delay it because we only release it
> > every so often and we *really* need a feature in.
> > 
> > I'd like to propose a change from having bugfix releases every month and
> > feature releases every ~6 months to just having a release every month.
> > 
> > In that release we would introduce both bugfixes and features.
> > 
> > We have been *very* good in the past with not introducing regressions
> > thanks to running the regression suite, so i think this is a good thing
> > since it makes it easier for our features to reach the users earlier
> > (e.g. i have a feature in poppler-qt that need to be released to make
> > okular faster).
> > 
> > The downside is that some distros won't like it, but honestly those
> > distros
> > already don't update some of the minor releases because we do changes to
> > our internal APIs so one can't fix distros.
> > 
> > Given the manpower we have at the moment (i.e. very low) i think a monthly
> > release (or maybe every two months) that contains both bugfixes and
> > features is the best for us.
> > 
> > Comments?
> 
> My only concern is the new public APIs, as you said we don't usually
> introduce severe regressions when adding features, but in the case of
> new API things are a bit different.

*New* API is fine.

> Breaking the API/ABI is problematic
> for everybody, and having an unstable cycle gives you the chance to test
> new APIs and change it if needed when actually used in the real
> world. Of course I'm talking about the qt/glib APIs, not the internal
> APIs.

Well, this means you have to test it before commiting it, should not be that 
hard. And well we can always either fix/break it (who wants/needs a broken API 
anyway) or introduce a V2 variant.

Cheers,
  Albert

> 
> We can make developer snapshots only when we introduce new API, and
> allow adding features to the stable branch.
> 
> Since we don't match our schedule with any distro or any other project,
> I don't see any problem if we don't release in time or whatever.
> 
> > Cheers,
> > 
> >   Albert
> > 
> > _______________________________________________
> > poppler mailing list
> > poppler@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/poppler

_______________________________________________
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler
[prev in list] [next in list] [prev in thread] [next in thread]