[poppler] Rethinking poppler releases

jose.aliste at gmail.com jose.aliste at gmail.com
Thu Sep 25 02:52:59 PDT 2014


Hey Albert, if you think it wont be much more burden for you at making the
releases, then please go for it. Having more releases make for easier
synchronization with KDE and GNOME schedules. Other than that, we could
also try to put a schedule every x months that is sync with KDE and GNOME
(and other desktops if necessary) so features needed for okular and evince
can be pushed sooner than later.


Greetings


José


On Wed, Sep 24, 2014 at 4:38 PM, Albert Astals Cid <aacid at kde.org> wrote:

> El Dimecres, 24 de setembre de 2014, a les 02:15:49, Maciej Mrozowski va
> escriure:
> > On Wednesday 24 of September 2014 00:51:06 Albert Astals Cid wrote:
> > | 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?
> > |
> > | Cheers,
> > |
> > |   Albert
> >
> > Sorry for maybe missing something obvious, but how about just releasing
> when
> > you feel there's something warranting the release instead of sort of
> > forcing yourself to do release cycles?
>
> Timed releases are the best for us, solves us from the issue of thinking
> "do
> we have enough to release?", yes we do because it's time.
>
> Cheers,
>   Albert
>
> >
> > While a little bit orthogonal, this could also involve choosing different
> > versioning method[1]. Patch releases whenever important enough fixes are
> > delivered (so that distros don't have to backport them from git).
> Introduce
> > major releases for "important" changes, minor releases for maybe less
> > "important", but preferably API backward compatible changes. "important"
> is
> > differently defined by different parties. For distros it could mean
> > "anything that breaks API or considerably enhances functionality".
> Poppler
> > is somewhat known for changing internal (XPdf?) API more than once so -
> > following distros' "important" definition - that could mean numerous
> major
> > releases if that API is considered public API, but hey..
> >
> > 1. http://en.wikipedia.org/wiki/Software_versioning#Change_significance
> >
> > regards
> > MM
> > _______________________________________________
> > poppler mailing list
> > poppler at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/poppler
>
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20140925/3b6e7e34/attachment.html>


More information about the poppler mailing list