El Dissabte, 27 de setembre de 2014, a les 09:11:37, Carlos Garcia Campos va escriure: > 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.
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 > >> > [email protected] > >> > http://lists.freedesktop.org/mailman/listinfo/poppler _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
