Subject: Re: [geometry] Maintaining released versions history
From: Menelaos Karavelas (menelaos.karavelas_at_[hidden])
Date: 2014-05-15 06:48:17
Hi all. I would like to share my 2 cents about this.
On 15/05/2014 02:57 ÏÎ¼, Adam Wulkiewicz wrote:
> I'd like to propose to somehow store the released versions history.
> What I'd like to achieve is to simplify the checking the difference
> between the develop and some released version.
> Also it would be possible to perform some quick fixes for a released
> version and preparing patches.
> In the GitFlow model this is probably achieved with tagging however
> I'm not sure about it and I don't know if we can/may do it on GitHub
> or/and in Boost?
> A simple alternative would be to create branches from master per
> release which means that we should made a decision and do it before
> the next merge of develop with master.
> What do you think?
From the MySQL point of view I think this would be very desirable.
Suppose you have released MySQL version X1 which depends on Boost/BG
version Y1, and now we are at MySQL version X2 > X1 which depends on
Boost/BG version Y2 > Y1. And now a user comes with a bug report for X1
which is actually a BG bug. In this case what would make sense to do is
to resolve the bug in Y1 (which will also resolve the bug in X1), and if
the bug is still there in Y2, also resolve it there (which will also
resolve the bug in X2).
This implies that X1 can still depend on Y1 (patched of course), and X2
can still depend on Y2 (again patched is needed), and things will work
This scenario would be very easy to implement if we have branches of
Boost releases in BG, and applying patches to these Boost releases would
simply mean branching from these releases and applying the patch to the
branch. Also if Boost decides to go from Y1.0 to Y1.1, then the branch
created from Y1 and has the patch applied can also be used for Y1.1
Hope that makes sense.
> Geometry mailing list
Geometry list run by mateusz at loskot.net