El Dijous, 25 de setembre de 2014, a les 06:52:59, [email protected] 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 doing releases since I need to do the betas and rc for the next one while doing the other releases, what i'm aiming is just at a simpler relase schedule that gives me/us less work. Cheers, Albert > > > Greetings > > > José > > On Wed, Sep 24, 2014 at 4:38 PM, Albert Astals Cid <[email protected]> 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 > > > [email protected] > > > http://lists.freedesktop.org/mailman/listinfo/poppler > > > > _______________________________________________ > > poppler mailing list > > [email protected] > > http://lists.freedesktop.org/mailman/listinfo/poppler _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
