[x265] Release version 3.1.2

[Aruna Matheswaran]

On Thu, Aug 1, 2019 at 7:04 PM Mario *LigH* Rohkrämer <contact at ligh.de>
wrote:

> Aruna Matheswaran schrieb am 01.08.2019 um 15:21:
> >
> >
> > On Wed, Jul 31, 2019 at 7:21 PM Mario *LigH* Rohkrämer <contact at ligh.de
> > <mailto:contact at ligh.de>> wrote:
> >
> >     Aruna Matheswaran schrieb am 31.07.2019 um 07:52:
> >      > Hi all,
> >      >
> >      > Version 3.1.2 of x265 is released with the fix for issue #498
> >      >
> >     <
> https://bitbucket.org/multicoreware/x265/issues/498/31rc-library-hangs-during-encoder_close
> >.
> >
> >      > Check out our downloads page
> >      > <https://bitbucket.org/multicoreware/x265/downloads/>for the
> tarball.
> >      >
> >      > Looking forward to your feedback.
> >      > --
> >      > Regards,
> >      > Aruna
> >      >
> >      >
> >      > _______________________________________________
> >      > x265-devel mailing list
> >      > x265-devel at videolan.org <mailto:x265-devel at videolan.org>
> >      > https://mailman.videolan.org/listinfo/x265-devel
> >
> >     I might be wrong, but ... tagging without merging may result in two
> >     parallel branches: "default" with the code and "release" with the
> tags.
> >     And if you are unlucky (like right now), the "tip" points to the
> newest
> >     tag with outdated code.
> >
> >
> > Mario, We have implemented a new release process in v3.1. The plan is to
> > maintain a separate branch for every release of x265.  All the bug fixes
> > specific to release "X.X" will be pushed to "Release_X.X" with a tag
> > "X.X.X" and the fix will be grafted to all the succeeding release
> > branches as well into default. This way the integrating application will
> > have the freedom to pick whichever version of x265 it wants as all the
> > bug fixes specific to that version will be available in the release
> > branch unlike earlier where all the bug fixes go into the tip of stable
> > and the user is forced to use the recent release of x265.
> >
> > Stable will get periodic merges from default and once an ample amount of
> > work goes into stable we'll create a new release branch and tag the new
> > version.
> >
> >
> >     --
> >
> >     Fun and success!
> >
> >     Mario *LigH* Rohkrämer
> >     maito:contact at ligh.de <mailto:maito%3Acontact at ligh.de>
> >     _______________________________________________
> >     x265-devel mailing list
> >     x265-devel at videolan.org <mailto:x265-devel at videolan.org>
> >     https://mailman.videolan.org/listinfo/x265-devel
> >
> >
> >
> > --
> > Regards,
> > Aruna
> >
> >
> > _______________________________________________
> > x265-devel mailing list
> > x265-devel at videolan.org
> > https://mailman.videolan.org/listinfo/x265-devel
>
>
> Thank you, Aruna. This way you will keep track of bugfixes.
>
> But it seems to me that the development of new features in the "default"
> branch will not be available in releases until you explicitly merge
> them. So testers will have either "unfixed" builds with new features or
> fixed builds with old features only ... until the fixed "release" branch
> may be merged with the experimental "default" branch once in a while.
>

As soon as we push a fix into release branch, we graft the same into
default. So, you should be getting new features with fixes in default.

>
> --
>
> Fun and success!
>
> Mario *LigH* Rohkrämer
> maito:contact at ligh.de
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>


-- 
Regards,
Aruna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20190801/cd6ea474/attachment.html>