[poppler] Rethinking poppler releases

[Carlos Garcia Campos]

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.

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

-- 
Carlos Garcia Campos
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20140927/6615f337/attachment.sig>