And if changes like this are added now, they will be included in 3.2.4
but not in 3.3.0. Is this bad?
This is the standard for any security fix: such a fix would be added to
3.1.6, 3.2.4, 3.3.1, and 3.4.0, but not to 3.2.3 or 3.3.0.
So
version(A) > version(B)
does not imply
has_fix(A, F)
On 28.08.2012 06:22, Petri Lehtinen wrote:
Georg Brandl wrote:
Changes to the default branch must be bugfix-only. The 3.4 development
only opens when the 3.3 branch is created, which happens after the
release of 3.3.0 final.
Changes made in default and not cherry-picked to the 3.3.0 release cl
Georg Brandl wrote:
> Changes to the default branch must be bugfix-only. The 3.4 development
> only opens when the 3.3 branch is created, which happens after the
> release of 3.3.0 final.
>
> Changes made in default and not cherry-picked to the 3.3.0 release clone
> will therefore end up in 3.3.1
On 26.08.2012 21:15, Chris Jerdonek wrote:
Now that the 3.3 release clone has been created, can someone clarify
what changes are allowed to go into the default branch? Is it the
same policy as if the changes were going into the release clone
directly (i.e. code freeze unless you have Georg's app
Now that the 3.3 release clone has been created, can someone clarify
what changes are allowed to go into the default branch? Is it the
same policy as if the changes were going into the release clone
directly (i.e. code freeze unless you have Georg's approval), or are
future changes for 3.3.1 okay,
