[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-25 22:22:38
Message-ID: 2423039.eWY32Hnfjm () xps
[Download RAW message or body]

El Dijous, 25 de setembre de 2014, a les 06:52:59, jose.aliste@gmail.com va =

escriure:
> 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.

The thing is, we already do a monthly release, but it's bugfix only, that =

delays features for a long time and at some points puts lots of effort in d=
oing =

releases since I need to do the betas and rc for the next one while doing t=
he =

other releases, what i'm aiming is just at a simpler relase schedule that =

gives me/us less work.

Cheers,
  Albert

> =

> =

> Greetings
> =

> =

> Jos=E9
> =

> On Wed, Sep 24, 2014 at 4:38 PM, Albert Astals Cid <aacid@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 mon=
th.
> > > | =

> > > | In that release we would introduce both bugfixes and features.
> > > | =

> > > | We have been *very* good in the past with not introducing regressio=
ns
> > > | 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 ma=
ke
> > > | 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 chang=
es
> > =

> > 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 releasi=
ng
> > =

> > 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. "importa=
nt"
> > =

> > 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_significan=
ce
> > > =

> > > regards
> > > MM
> > > _______________________________________________
> > > 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

_______________________________________________
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]