incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Costa <igorco...@gmail.com>
Subject Re: next release 4.9 or 4.8.1?
Date Tue, 24 Jul 2012 18:13:35 GMT
Carol


I must agree on 4.8.1 to fix bugs on the current release and quite fit the
way Apache does for other projects.

When we have new components going on under 4.8.x We will more confident to
release 4.9


Best Regards
----------------------------
Igor Costa
www.igorcosta.com
www.igorcosta.org


On Tue, Jul 24, 2012 at 11:10 AM, Carol Frampton <cframpto@adobe.com> wrote:

> I thought about this a bit more last night after I sent the mail.
>
> My vote would be to set up trunk to be 4.8.1 but I think we could use at
> least one, for flex.next which could become either 4.9 or 5.0.  Or rather
> than a branch for each version, have trunk as the stable branch and one or
> more branches with various degrees of stability.  I think I remember Roy
> saying httpd did it this way.  When a feature became "ready" it is merged
> to trunk.
>
> As someone tweeted last night, I branched trunk to
> whiteboard/cframpton/adobe.next yesterday which will be populated with the
> Adobe flex5 work as soon as it gets legal clearance.  Some of the incoming
> code is completely done, some completely done and tested, and some in
> various states of doneness. There are also just general bug fixes.  Once
> we've picked this apart and decide what we want and what we don't want it
> would be good to have a branch to put the "keep" code in since I don't
> think much of it, other than bug fixes, belongs in trunk.
>
> Just fyi, currently changing versions requires a few too many hand-edits
> of various files. Minimally I want to do it one more time and document all
> the places, but automating it would be even better.
>
> Carol
>
>
> On 7/23/12 4 :44PM, "Carol Frampton" <cframpto@adobe.com> wrote:
>
> >Any predictions what will be the next released version? I'd like to bump
> >the version numbers before I go off and do some non-build work.  If we
> >guess wrong we go always go back and change them again.
> >
> >Carol
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message