[poppler] Rethinking poppler releases

[Albert Astals Cid]

El Dissabte, 27 de setembre de 2014, a les 09:11:37, Carlos Garcia Campos va 
escriure:
> Albert Astals Cid <aacid at kde.org> writes:
> > El Divendres, 26 de setembre de 2014, a les 14:35:10, Carlos Garcia Campos
> > va> 
> > escriure:
> >> Albert Astals Cid <aacid at 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.
> 
> I wish it was always as easier as test it before committing,
> unfortunately that's not always the case. In any case, I can implement
> ways of adding semi-public API, something like protecting new risky API
> with THIS_IS_UNSTABLE_I_KNOW_WHAT_IM_DOING or similar macro that the
> user has to define to be able to use it. Once I consider that's stable I
> only need to remove the ifdefs.
> 
> So, I'm definitely fine with any solution that allows us to progress
> quickly and reduce the maintenance work for you.

Ok then let's try this for a while and see how it goes. I will release 0.26.5 
today and then we go with 0.28 next month, 0.30 in two months, etc.

All releases will be tagged from master.

After a few months (let's say half a year) we can evaluate how this has gone 
and if we need to go back to the old ways.

Cheers,
  Albert

> 
> > 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 at lists.freedesktop.org
> >> > http://lists.freedesktop.org/mailman/listinfo/poppler