First Flex release as soon as possible? (was: So, what should we do first?)

[Bertrand Delacretaz]

On Thu, Jan 5, 2012 at 1:42 AM, Alex Harui <[hidden email]> wrote:
> ...I recall from the summit that a healthy Apache project releases at least every 4 to 6 months, and one of the things an incubator podling has to do is cut at least one release so it can show it knows the Apache way of doing so.  So, while we’ve got lots of good ideas out there around refactoring Flex, lots of those seem like more than a 4 to 6 month project...

There's no Apache rule as to how often a project should release, I've
seen cycles going from once a week to once a year. More than a year
without a release might raise some eyebrows but it there's a good
reason it's possible as well.

I would suggest making a first Flex release much earlier than that, as
soon as possible, to get familiar with the Apache release process.

The result might not be better than the current Flex release (in which
case we'd mark it as such), but that would help make sure the release
process is in place and committers understand it.

I imagine there will be lots of small issues along the way of creating
a valid Apache release, and it's better IMO to tackle this early, even
if the result is a release that's not very interesting to Flex users.

-Bertrand

[Rui D. Silva]

+1

> I would suggest making a first Flex release much earlier than that, as
> soon as possible, to get familiar with the Apache release process.

I would go as far as to suggest that the first Apache Flex release should
equivalent in code to the current Adobe Flex 4.6 release. This would
guarantee that there is no gap in terms of code between the Adobe era and
the Apache era.

Rui

[David Arno]

+1


> +1

>> I would suggest making a first Flex release much earlier than that, as
>> soon as possible, to get familiar with the Apache release process.

>I would go as far as to suggest that the first Apache Flex release should
equivalent in code to the current Adobe Flex 4.6 release. This would
guarantee that >there is no gap in terms of code between the Adobe era and
the Apache era.

>Rui

Not sure if I can +1 as I'm not a committer, so ignore this if I can't :)

David.

[Iwo Banaś]

+1

> I would go as far as to suggest that the first Apache Flex release should
> equivalent in code to the current Adobe Flex 4.6 release.

We can even keep the version as Apache Flex 4.6 to avoid the impression
that we are releasing some new features.

Cheers,
Iwo Banas

[Valdemar Lopes]

+1

-----Mensagem Original-----
From: Iwo Banaś
Sent: Thursday, January 05, 2012 11:59 AM
To: [hidden email] ; [hidden email]
Subject: re: First Flex release as soon as possible? (was: So, what should
we do first?)

+1

> I would go as far as to suggest that the first Apache Flex release should
> equivalent in code to the current Adobe Flex 4.6 release.

We can even keep the version as Apache Flex 4.6 to avoid the impression
that we are releasing some new features.

Cheers,
Iwo Banas

[Michael Schmalle]

Quoting Iwo Bana? <[hidden email]>:

> +1
>
>> I would go as far as to suggest that the first Apache Flex release should
>> equivalent in code to the current Adobe Flex 4.6 release.
>
> We can even keep the version as Apache Flex 4.6 to avoid the impression
> that we are releasing some new features.
>
> Cheers,
> Iwo Banas
>

+1

Seems logical to keep the time-line intact, so there is no majic at  
work, just transferring.

Mike

[David Arno]

> From: Iwo Banaś [mailto:[hidden email]]
> Sent: 05 January 2012 11:59
>> I would go as far as to suggest that the first Apache Flex release
>> should equivalent in code to the current Adobe Flex 4.6 release.
>
> We can even keep the version as Apache Flex 4.6 to avoid the impression
that we are releasing some new features.

I completely agree with this. Also it would be good to do this with Apache
Flex 3.6 too for those of us who still need to use Flex 3.

David.

[El Koro]

From: "Iwo Banas" <[hidden email]>
>> I would go as far as to suggest that the first Apache Flex release should
>> equivalent in code to the current Adobe Flex 4.6 release.
>
> We can even keep the version as Apache Flex 4.6 to avoid the impression
> that we are releasing some new features.

I don't -1 it, but maybe this should require some thoughts.
If Apache would release a 4.6 SDK without any other benefit than a name
change (keep in mind that the Adobe one is already open-source), and even
with real drawbacks (no cached RSLs, maybe some tooling/IDE little issues),
who would use it over the Adobe 4.6 one?

I understand the "spirit" behind it, but I think there is so much to do
right now, that putting some of "our" ressources in a "symbolic" release
would not be a good first step in our new era.
In Adobe's usual words, how much of your 100$ are you ready to invest in a
symbolic release ;)

[Valdemar Lopes]

+1

-----Mensagem Original-----
From: David Arno
Sent: Thursday, January 05, 2012 12:52 PM
To: [hidden email]
Subject: RE: First Flex release as soon as possible? (was: So, what should
we do first?)

> From: Iwo Banaś [mailto:[hidden email]]
> Sent: 05 January 2012 11:59
>> I would go as far as to suggest that the first Apache Flex release
>> should equivalent in code to the current Adobe Flex 4.6 release.
>
> We can even keep the version as Apache Flex 4.6 to avoid the impression
that we are releasing some new features.

I completely agree with this. Also it would be good to do this with Apache
Flex 3.6 too for those of us who still need to use Flex 3.

David.

[Iwo Banaś]

> I understand the "spirit" behind it, but I think there is so much to do
right now, that putting some of "our" ressources in a "symbolic" release
would not be a good first step in our new era.

I don't consider this to be a "symbolic" release. It's more the release
exercise and setting a baseline for regression testing. I agree that it
will be a small step back from the user perspective so probably not many
people will use it for prod but that's not a problem. We can make a big
step forward in couple months and be sure that the first feature release
will go smoothly.

Cheers,
Iwo Banas

[Frédéric THOMAS]

+1 Dimitri,
Even if the interest to be sure of the feasibility of the transition from the Adobe's model to the Apache one is important, this version should never be public for the reasons you mention, what do you think commiters ?
Frédéric Thomas    

[Bertrand Delacretaz]

On Thu, Jan 5, 2012 at 12:48 PM, David Arno <[hidden email]> wrote:
> ...Not sure if I can +1 as I'm not a committer, so ignore this if I can't :)

All opinions are welcome, so thanks for your +1.

When voting (in a thread that's clearly identified by [VOTE] in its
subject), only votes from PMC members (so PPMC in the case of a
podling like Flex) are counted, but even then everybody's welcome to
express their opinion by casting a vote.

-Bertrand

[Bertrand Delacretaz]

On Thu, Jan 5, 2012 at 2:22 PM, Web DoubleFx <[hidden email]> wrote:
> ...Even if the interest to be sure of the feasibility of the transition from the Adobe's model to the Apache one is important, this version should never be public for the reasons you mention, what do you think commiters ?...

As far as the Incubator is concerned, a release doesn't exist if it's
not public.

So if the first Apache Flex release is not interesting to users, we
should just label it as such, but it will still be public.

Creating it will IMO be a very useful exercise for this podling, and
it will be an important milestone towards graduating Flex.

-Bertrand

[Rui D. Silva]

I think the main objective here would be to reassure that the code base from the Apache Flex project stems directly from the Adobe code.

Being able to run it through the existing tooling is an interesting side effect that I was not considering but could act as a test case of sorts in order to perceive early on where Apache Flex would break or function differently with existing tooling.

Other benefit would be that tooling vendors, Adobe included, could test Apache Flex early on and see what sort of changes were needed to make it usable with their producs.

To the final developer it would be like saying: "Hey Adobe has donated Flex to Apache and to make sure that your products will work using Apache's version of Flex, here is an initial build from the donated code base. These are the thing that are different between the two (...), but this should not have a major effect on your work. Going forward and knowing these differences, it's your choice as to which version to use."

Rui

[Rui D. Silva]

I, actually don't see a problem with this initial build being public as long as the messaging is clear.

Rui

[El Koro]

From: "Bertrand Delacretaz" <[hidden email]>
> As far as the Incubator is concerned, a release doesn't exist if it's
> not public.
> So if the first Apache Flex release is not interesting to users, we
> should just label it as such, but it will still be public.
> Creating it will IMO be a very useful exercise for this podling, and
> it will be an important milestone towards graduating Flex.

Valid points.
Maybe it was more the talk about 3.5 Apache release that made me worried we
waste some steam on things nobody would use.

If the point is to have the podling practice an Apache release, and if this
is labeled as such, I withdraw the doubts I've emitted earlier.
+1 for a "practice" 4.6 Apache Flex release

[Carol Frampton]

>
>Creating it will IMO be a very useful exercise for this podling, and
>it will be an important milestone towards graduating Flex.
>
>-Bertrand


+1.  I am the person who has been modifying the build files and source
tree for the last couple of weeks in preparation for getting the code over
to Apache.  Because of some of the thirdparty issues there are changes.  I
think it is a very wise idea to go thru an entire release cycle before any
real code changes have been made to make sure we transitioned everything
correctly and we understand the release process.

[Ryan Frishberg]

+1

It sounds like a good idea to do a simple release and keep messaging
clear about it.

As a next step, and to keep commits simple, I think working towards a
4.7 bug fix-only release might also be a good idea. I like the
enthusiasm on the list for broad changes, but I am just worried about
some of them :). I think concentrating on doing less controversial bug
fixes will help us figure out the commit/review process with less
disagreements about the direction of the SDK to start with.

@Bertrand, with regards to voting, does that mean we shouldn't respond
with "+1" unless the title of the thread is "[VOTE]".  If something
comes up in a thread that requires a vote, should we always create a
separate "[VOTE]" thread for that issue?

-Ryan

On 05/01/2012, Carol Frampton <[hidden email]> wrote:

>
>
>>
>>Creating it will IMO be a very useful exercise for this podling, and
>>it will be an important milestone towards graduating Flex.
>>
>>-Bertrand
>
>
> +1.  I am the person who has been modifying the build files and source
> tree for the last couple of weeks in preparation for getting the code over
> to Apache.  Because of some of the thirdparty issues there are changes.  I
> think it is a very wise idea to go thru an entire release cycle before any
> real code changes have been made to make sure we transitioned everything
> correctly and we understand the release process.
>
>

--
Sent from my mobile device

[David Arno]

> From: Dimitri k. [mailto:[hidden email]]
> Sent: 05 January 2012 13:37
>
> Maybe it was more the talk about 3.5 Apache release that made me
> worried we waste some steam on things nobody would use.

Am I the only one stuck having to use 3.5 / 3.6 then? Or is it more the case that there is no benefit in diverting resources to improving Flex 3, so why even bother creating an Apache version of it?

David.

[Jeff Tapper]

>Valid points.
>Maybe it was more the talk about 3.5 Apache release that made me worried we waste some steam on things nobody would use.

For what it is worth, We still have a number of clients using the Flex 3.x SDK