Albert Astals Cid <[email protected]> writes: > El Divendres, 26 de setembre de 2014, a les 14:35:10, Carlos Garcia Campos va > escriure: >> Albert Astals Cid <[email protected]> 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 >> > [email protected] >> > http://lists.freedesktop.org/mailman/listinfo/poppler > -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462
pgpn6z0TMazr8.pgp
Description: PGP signature
_______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
