Libical: Help with next release
Allen Winter
winter at kde.org
Mon Dec 19 05:45:01 PST 2016
On Monday, December 19, 2016 10:30:35 AM Milan Crha wrote:
> On Sat, 2016-12-17 at 10:03 -0500, Allen Winter wrote:
> > At this point I'm only interested in issues marked with the 2.1
> > milestone.
> > https://github.com/libical/libical/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.1.0
Right, sorry about that.
I renamed the milestone to 3.0, so the url is changed to:
https://github.com/libical/libical/issues?q=is%3Aopen+is%3Aissue+milestone%3A3.0.0
>
> Hi,
> the above link returns no results to me.
>
> > I'm trying to make sure the code is binary compatible with libical
> > 2.0. If not, we might call this version 3.0 instead of 2.1.
>
> Is there any requirement to bump the major version when changing API in
> the libical project? I usually do not bump the major version when
> changing API, I do change the soname versions (which are versioned
> independently from the actual project version).
No requirement. but in this case I really want to make it clear
that the new release won't be binary compatible or source compatible.
(since we are removing deprecated functions).
>
> Just as an example, I do not like the way FireFox versioning is done,
> they'll reach version 100 "soon", but what it is good for is unknown to
> me. I prefer to use major version changes for really major changes in
> the project, like when switching from gtk2 to gtk3, the evolution
> projects switched from 2.x.x to 3.x.x. It's still 3.y.y despite
> changing API several times during the time.
> Bye,
> Milan
>
> _______________________________________________
> libical-devel mailing list
> libical-devel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libical-devel
More information about the libical-devel
mailing list