Re: Grilo Releases
- From: "Juan A. Suarez Romero" <jasuarez igalia com>
- To: grilo-list gnome org
- Subject: Re: Grilo Releases
- Date: Thu, 04 Oct 2012 23:54:25 +0200
On Mon, 2012-08-13 at 20:14 +0200, Juan A. Suarez Romero wrote:
> Hello!
>
> As you have seen, I've released both 0.1.20 and 0.2.0 versions.
>
> 0.1.20 is the last of the 0.1.x series. I will write a couple of blog
> posts explaining how to migrate from 0.1.x to 0.2.0, step by step.
>
> From now on, these are the rules for the releases I'll stick as much as
> possible:
>
>
Hello.
Some days ago I released grilo 0.2.1, both core and plugins. But the
cool TMDb plugin was not included in the set, because it requires a new
function from core that was not included. The reason for not including
it was that, as announced, I was following the same policy as GNOME for
core libraries: stable version has its API/ABI frozen, so we can't
change nor add new API.
But after talking with Bastien, and thinking about it, I think that
policy is a bit strong for our case. That is, it is fine with no
breaking the API so applications still work with new releases; but
adding a new function doesn't mean necessarily that we are breaking it.
So basically I'll relax the rule allowing adding new API to a release
series.
And coming to this point, I've also realized that keeping two branches,
one for stable versions (0.2.x) and another for unstable versions
(master), is complicating me the life of maintaining, and doesn't
provide nothing really useful at this moment: mostly both branches
contain exactly the same commits.
Honestly, I think it is too early to think in having a stable/unstable
series, because we aren't changing the API so frequently to make it
worth.
For this reason, I'm moving master to point to 0.2. versions, and
removing the 0.2.x branch.
Summing up:
* Branch 0.2.x dissapears
* Master will contain 0.2.x code
* During the life of 0.2, we are allowed to add new API (providing that
we don't break the ABI), but not changing or removing API.
* In the same moment we need to break it, we will branch master to 0.2.x
(so we can still do fixes in that API version), and convert master in
the next series (0.3.x in this case).
I hope this simplification makes our life easier.
Regards,
J.A.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]