flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: AW: AW: Changing our release strategy?
Date Fri, 05 Sep 2014 17:46:45 GMT
I don't know BlazeDS that well.  What needs to be re-written to make a new
turnkey war work?  Will customers with existing wars need to upgrade them
to use the Apache Flex version of BlazeDS as well?

I'm fine with moving stuff to an attic branch, but I'm just wondering if
we're seeing warning signs of a backward-compatility problem that will hit
BlazeDS users.


On 9/5/14 10:30 AM, "Christofer Dutz" <christofer.dutz@c-ware.de> wrote:

>Ok so let me re-phrase my mail,
>there are a lot of testcases that will definitely not work with the
>current build. Not even the build will work.
>I agree, having a turnkey war with examples is a good thing, but in order
>to have this, we would need to re-write most of that code anyway.
>Perhaps re-creating the turnkey war as a maven project is better than
>trying to get the old solution to build.
>We could then add that to the maven build and rid ourselves of the
>obsolete rest (We could park that in some sort of Attic (branch)). I just
>want to prevent us from having a release until the rest works again.
>Von: Alex Harui <aharui@adobe.com>
>Gesendet: Freitag, 5. September 2014 18:36
>An: dev@flex.apache.org
>Betreff: Re: AW: Changing our release strategy?
>On 9/5/14 5:51 AM, "Christofer Dutz" <christofer.dutz@c-ware.de> wrote:
>>Well then: Please help with the legal issues required to release BlazeDS
>>I would even recommend to clean up the project and throw out the old
>>stuff surrounding the "modules" directory, which seems to be the only
>>part that's needed. I would like to tag BlazeDS and then move everything
>>in the modules directory to become the new project root. This would
>>eliminate the entire confusion.
>Not sure what you mean by "throw out".  I think there are some tests that
>might be useful to have, if not now, then someday, and some default
>samples for a BlazeDS TomCat server.  If you mean "not package in a source
>release" then yes, IMO no need to package the qa stuff in the source
>release.  In a binary convenience release, why wouldn't it be desirable to
>have a default TomCat setup with examples to help folks get going?

View raw message