+1
-Mark
-Original Message-
From: Harbs [mailto:harbs.li...@gmail.com]
Sent: Tuesday, December 09, 2014 2:57 AM
To: dev@flex.apache.org
Subject: Re: [RESULT][VOTE] - Allow RC votes to carry over at any point in the
release process
Alright. I just removed the entire line. It jives with
;Erik de Bruin" wrote:
> >
> >> I had to read the 'oversight' line twice to catch it's meaning. I have
> >> suggested an alternative, please take a look.
> >>
> >> EdB
> >>
> >>
> >>
> >> On Tue, Dec 9, 2014 at 7:58 AM,
>>
>>
>> On Tue, Dec 9, 2014 at 7:58 AM, Harbs wrote:
>>> Done. I added a sentence defining “carrying” as “oversight”.
>>>
>>> On Dec 9, 2014, at 2:18 AM, Alex Harui wrote:
>>>
>>>> Maybe I’m being too picky, but the vote proposal
gt;> On Dec 9, 2014, at 2:18 AM, Alex Harui wrote:
>>
>>> Maybe I’m being too picky, but the vote proposal said: "I suggest that
>>>at
>>> any point in the release process a vote should be carried over if the
>>> person voting indicates they wish th
e:
>> Done. I added a sentence defining “carrying” as “oversight”.
>>
>> On Dec 9, 2014, at 2:18 AM, Alex Harui wrote:
>>
>>> Maybe I’m being too picky, but the vote proposal said: "I suggest that at
>>> any point in the release process a vote should b
Harui wrote:
>
>> Maybe I’m being too picky, but the vote proposal said: "I suggest that at
>> any point in the release process a vote should be carried over if the
>> person voting indicates they wish the vote should carry over.”
>>
>> The current wiki vers
Done. I added a sentence defining “carrying” as “oversight”.
On Dec 9, 2014, at 2:18 AM, Alex Harui wrote:
> Maybe I’m being too picky, but the vote proposal said: "I suggest that at
> any point in the release process a vote should be carried over if the
> person voting indicates
lines.
EdB
On Tuesday, December 9, 2014, Alex Harui wrote:
> Maybe I’m being too picky, but the vote proposal said: "I suggest that at
> any point in the release process a vote should be carried over if the
> person voting indicates they wish the vote should carry over.”
&
Maybe I’m being too picky, but the vote proposal said: "I suggest that at
any point in the release process a vote should be carried over if the
person voting indicates they wish the vote should carry over.”
The current wiki version says: "The release manager can carry over of
votes fro
> >> >>
> >> >> that's not Apache policy.
> >> >
> >> > What did Bertrand *just say* in the post with subject "[TTH] it's not
> >> that
> >> > complicated" ?
> >> > Stuff like this *doesn't hav
gt; >> that's not Apache policy.
>> >
>> > What did Bertrand *just say* in the post with subject "[TTH] it's not
>> that
>> > complicated" ?
>> > Stuff like this *doesn't have an Apache policy*.
>> >
>>
I don’t see my last two emails in the archives. Sorry if this is going out more
than once…
Here is a link to the modified wiki.[1] I think the changes are pretty minor… I
removed mention of carried votes from the voting timeframe section, and
clarified the wording in the “Product Release” secti
otes to carry over at any point in the release
> process
> To: "dev@flex.apache.org"
>
>
> This vote passed with 6 +1 binding votes and one -1 binding votes.
>
> This vote is somewhat moot in light of the recent discussions and
> clarifications of what different p
Here is a link to the modified wiki.[1] I think the changes are pretty minor… I
removed mention of carried votes from the voting timeframe section, and
clarified the wording in the “Product Release” section.
Harbs
[1]https://cwiki.apache.org/confluence/display/FLEX/Guidelines
Raising visibility :-)
-- Forwarded message --
From: *Harbs*
Date: Monday, December 8, 2014
Subject: [VOTE] Allow RC votes to carry over at any point in the release
process
To: "dev@flex.apache.org"
This vote passed with 6 +1 binding votes and one -1 binding votes.
This vote passed with 6 +1 binding votes and one -1 binding votes.
This vote is somewhat moot in light of the recent discussions and
clarifications of what different people mean by “carried votes”, but I will
edit the guidelines shortly to reflect what I believe was the spirit of the
vote. If a
t with subject "[TTH] it's not
> that
> > complicated" ?
> > Stuff like this *doesn't have an Apache policy*.
> >
> > It's also very unclear who you were responding too and about what.
> > Probably because you are replying to a bounce messa
Probably because you are replying to a bounce message or something, I think
> ?
>
> Assuming you mean some minor point that you feel hasn't been discussed
> enough in the new release process we're adopting, why does what Erik
> suggested (my emphasis):
>
> "
> discussion on
Justin,
Please see [1]. I don't accept the veto, as I don't see how changing a
wiki text is against Apache policy.
I've reworded the sentence to make it's intention clearer. It's a
practical one statement, meant to help an RM avoid starting a release
that nobody else cares enough about to help wi
out what.
Probably because you are replying to a bounce message or something, I
think ?
Assuming you mean some minor point that you feel hasn't been discussed
enough in the new release process we're adopting, why does what Erik
suggested (my emphasis):
"
discussion on the proces
Hi,
> This message wasn't delivered as I suspect you intended.
In that it wasn't sent to dev? OK resending to dev.
-1 (and that's a veto). Please revert these changes and open to discussion
first. Why? There's been no agreement on "After polling the dev@ list to see
if there is enough interes
Hi,
> Everyone had the opportunity to review the commit that changed the NOTICE,
The error was in the previous 2 RCs and also in the 1.1 release [1] which also
went though a couple of RCs. IMO that points to that we need more PMC members
checking releases. Which I guess ties into the thread on
On Dec 5, 2014 11:51 PM, "Justin Mclean" wrote:
>
> Hi,
>
> > This is again a case of misleading characterization of the issue in
hand.
>
> Sorry I don't believe it is.
>
> The board requires oversight on releases and that means Majority Approval
(ie 3 binding +1 votes) the release only had 2 +1 b
Hi,
> This is again a case of misleading characterization of the issue in hand.
Sorry I don't believe it is.
The board requires oversight on releases and that means Majority Approval (ie 3
binding +1 votes) the release only had 2 +1 binding votes. In this case it
could be called into question
ing wording for the change. At this time i'll
vote:
+0 binding
As I agree with the spirit of the change and I am very confident that the team
will figure out the detail of the language or even if any would be required.
[1]
http://apache-flex-development.2333347.n4.nabble.com/VOTE-Allow-RC-v
On 12/5/14, 11:22 AM, "OmPrakash Muppirala" wrote:
>On Fri, Dec 5, 2014 at 11:11 AM, Rich Bowen wrote:
>
>>
>>
>> On 12/05/2014 07:59 AM, Justin Mclean wrote:
>>
>>> Being the RM and making a release has a legal responsibility. I don't
>>> think we should be forcing the RM to be doing anything
On Fri, Dec 5, 2014 at 11:11 AM, Rich Bowen wrote:
>
>
> On 12/05/2014 07:59 AM, Justin Mclean wrote:
>
>> Being the RM and making a release has a legal responsibility. I don't
>> think we should be forcing the RM to be doing anything that has potential
>> legal issues. The incident that this VO
On 12/05/2014 07:59 AM, Justin Mclean wrote:
Being the RM and making a release has a legal responsibility. I don't think we
should be forcing the RM to be doing anything that has potential legal issues.
The incident that this VOTE has arisen from was about changing NOTICE and then
making a
sn't all sunshine and lolipops without
> taking it personally. :) I was just giving my first impressions, which I
> think were legitimate since 90% of the messages coming in so far was
> arguing over the release process and the release manager heralding the end
> of the universe
rguing over the release process and the release manager heralding the end
of the universe if we all carry on against his advice.
Anyway yes I do have genuine concerns about corporate independence. Your
profile says that you work for Adobe, right? I don't see how that in itself
doesn&
On Fri, Dec 5, 2014 at 5:25 PM, Jesse Nicholson
wrote:
> ...many of the leads here seem to double as adobe
> employees... which makes me feel that this is still very heavily controlled
> and owned by adobe for their own corporate interests
I suppose you did not realize how that kind of statem
ide perspective.
>
> -Mark
>
> -Original Message-
> From: Jesse Nicholson [mailto:ascensionsyst...@gmail.com]
> Sent: Friday, December 05, 2014 11:25 AM
> To: dev@flex.apache.org
> Subject: Re: [VOTE] Allow RC votes to carry over at any point in the
> release proce
+1 binding
On Dec 5, 2014 4:58 AM, "Frédéric THOMAS" wrote:
> +1 (Binding)
> Frédéric THOMAS
carry over at any point in the release
process
I just have to say as a new member here looking to possibly get involved,
that all of this back and forth arguing over the release process and all
the terror of the legality of changing things really makes for a terrible
first impression. I'm p
I just have to say as a new member here looking to possibly get involved,
that all of this back and forth arguing over the release process and all
the terror of the legality of changing things really makes for a terrible
first impression. I'm pretty discouraged about any participation. Betwee
> ... without much discussion ...
LOL
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Hi,
-1 (binding)
To change the guidelines it would be better to propose a vote with actual word
changes to the guidelines, but that's not why I'm voting -1.
Being the RM and making a release has a legal responsibility. I don't think we
should be forcing the RM to be doing anything that has pot
+1 (Binding)
Frédéric THOMAS
On 05/12/14 12:29, Erik de Bruin wrote:
As a side note: PMC members should really add " (binding)" to their
votes. That will save the vote caller the trouble of having to look up
each individual's status when calling the result.
I didn't know this and I'm on the PMC :-)
I've noted it on as this
[mailto:valdemarlo...@gmail.com]
Sent: Friday, December 05, 2014 7:35 AM
To: dev@flex.apache.org
Subject: Re: [VOTE] Allow RC votes to carry over at any point in the release
process
Please remove me from this list
smime.p7s
Description: S/MIME cryptographic signature
+1 (Binding)
Redone for clarity in vote counting.
-Mark
-Original Message-
From: Kessler CTR Mark J [mailto:mark.kessler@usmc.mil]
Sent: Friday, December 05, 2014 7:22 AM
To: dev@flex.apache.org
Subject: RE: [VOTE] Allow RC votes to carry over at any point in the release
process
; Sent: Friday, December 05, 2014 5:56 AM
> To: dev@flex.apache.org
> Subject: [VOTE] Allow RC votes to carry over at any point in the release
> process
>
> I suggest that at any point in the release process a vote should be
> carried over if the person voting indicates they wish the vote should carry
> over.
>
> +1
>
> Harbs
>
As a side note: PMC members should really add " (binding)" to their
votes. That will save the vote caller the trouble of having to look up
each individual's status when calling the result.
Thanks,
EdB
On Fri, Dec 5, 2014 at 1:24 PM, Erik de Bruin wrote:
>> I like the idea. Barring we do not
> I like the idea. Barring we do not allow new features to be added in between
> RC's.
The 'less-RC' proposal is very explicit about this: no new features in
the RCs, to be more specific: no new features in the release after the
release branch has been cut.
EdB
--
Ix Multimedia Software
Ja
n the release process
I suggest that at any point in the release process a vote should be carried
over if the person voting indicates they wish the vote should carry over.
+1
Harbs
week.
Tom
On 05/12/14 10:55, Harbs wrote:
I suggest that at any point in the release process a vote should be carried
over if the person voting indicates they wish the vote should carry over.
+1
Harbs
__
This email has been
+1 (binding)
The RM should treat an explicit statement indicating the wish to carry
over a vote the same as voting again.
EdB
On Fri, Dec 5, 2014 at 11:55 AM, Harbs wrote:
> I suggest that at any point in the release process a vote should be carried
> over if the person voting ind
I suggest that at any point in the release process a vote should be carried
over if the person voting indicates they wish the vote should carry over.
+1
Harbs
On 11/5/14, 1:32 PM, "Justin Mclean" wrote:
>Hi,
>
>I'll also point out that what is currently being looked at it identical
>to RC0 that I called a vote on a week ago, so there would be no need to
>cancel that vote and call another one.
I think the MD5s probably changed. SWFs built at differe
Hi,
I'll also point out that what is currently being looked at it identical to RC0
that I called a vote on a week ago, so there would be no need to cancel that
vote and call another one.
There's only been one change made to the release branch which was an addition
of a MD5 check by Alex and IM
Hi,
> If the people who said they were looking at something have reported back,
> if all promised fixes have been committed and if all tweaks to the docs
> have been made - in other words, when the release branch has stabilised
> the RM decides when to call the vote.
IMO That is currently the ca
>
> OK we currently have two (minor) issues which I'm unable to produce
> locally. And I have no idea if any PMC members have checked the important
> things like hashes and the like. How do we progress from here? How does the
> RM decide when it's time call a vote? So far this process has taken lon
Hi,
OK we currently have two (minor) issues which I'm unable to produce locally.
And I have no idea if any PMC members have checked the important things like
hashes and the like. How do we progress from here? How does the RM decide when
it's time call a vote? So far this process has taken longe
+1 to this.
-Original Message-
I like this idea to have a special nightly build for releases during the
release process. It seems to me that it should simplify the process all
around.
Harbs
The nightly source builds can be found here:
http://apacheflexbuild.cloudapp.net:8080/job/flex-utilities_tour-de-flex-release/lastSuccessfulBuild/artifact/TourDeFlex/TourDeFlex3/out/
The nightly 'binary' build can be viewed here (for the time being, until I
figure out a way to archive that proper
Waiting on for the 'flex-sdk' job to finish so I can try the new TDF
release build.
EdB
On Tue, Nov 4, 2014 at 9:18 AM, Justin Mclean
wrote:
> Hi,
>
> > That is not at all what I wrote. Please read emails more carefully
>
> I did read it carefully you said "It takes very little effort for the
Hi,
> That is not at all what I wrote. Please read emails more carefully
I did read it carefully you said "It takes very little effort for the release
manager to set up a copy of the build of the develop branch".
Given it takes very little effort and you now say that it's not the release
mana
>
> > That was very selective quoting ... I clearly state "the latest HEAD from
> > the release branch."
>
> So we would need to either alter existing CI jobs and add additional ones
> every time a release branch is made?
>
That is not at all what I wrote. Please read emails more carefully ... I
r
Hi,
> That was very selective quoting ... I clearly state "the latest HEAD from
> the release branch."
So we would need to either alter existing CI jobs and add additional ones every
time a release branch is made?
> It takes very little effort for the release manager to set up a copy of the
> b
I like this idea to have a special nightly build for releases during the
release process. It seems to me that it should simplify the process all around.
Harbs
On Nov 4, 2014, at 9:38 AM, Erik de Bruin wrote:
>>
>>> I'd go (and will go) one further, and use nightli
>
> > I'd go (and will go) one further, and use nightlies during this phase.
>
> How would that be possible given nightly are off the develop branch not a
> release branch. Other people may check stuff into develop that we don't
> want in the release under consideration. Also currently there are no
Hi,
> I'd go (and will go) one further, and use nightlies during this phase.
How would that be possible given nightly are off the develop branch not a
release branch. Other people may check stuff into develop that we don't want in
the release under consideration. Also currently there are no nig
On 11/3/14, 11:24 PM, "Justin Mclean" wrote:
>Hi,
>
>>> For TDF, because it is an “app”, if you want more feedback, it might be
>>> reasonable to post a deployed version of TDF somewhere like your
>>>personal
>>> folder
>
>It will take an hour or so to upload a tar of the files via scp to
>peop
Hi,
>> For TDF, because it is an “app”, if you want more feedback, it might be
>> reasonable to post a deployed version of TDF somewhere like your personal
>> folder
It will take an hour or so to upload a tar of the files via scp to
people.apache.org. Part of the reason we don't have a binary r
>
> > If issues are found during the discussion phase, you can just drop a
> new package over the old package.
>
> -1 to this as this will cause all sort of confusion to exactly what
> version an issue was in or what version people tested and this could more
> RCs rounds not less and a lot more wo
Hi,
> I expected the next step is that you put up a release candidate and open a
> [DISCUSS] thread, but not a [VOTE] thread.
Fair enough. I have opens a discuss thread but had very little response. Given
we had a discussion open for over a week and no major issues have been found
what do you r
+1
Excellent summary!
EdB
On Tuesday, November 4, 2014, Alex Harui wrote:
>
>
> On 11/3/14, 3:30 PM, "Justin Mclean" > wrote:
>
> >Hi,
> >
> >I asked for feedback over a period of a week and only feedback was to
> >change a title. Without a release candidate is seens to me that people are
>
On 11/3/14, 3:30 PM, "Justin Mclean" wrote:
>Hi,
>
>I asked for feedback over a period of a week and only feedback was to
>change a title. Without a release candidate is seens to me that people are
>unwilling to check things.
Right, I understood the prior thread to be a “last call for new feat
Hi,
> I would say that during the “last call”, if nobody speaks up with a plan
> to commit stuff soon that shouldn’t be put into the release, that a
> release branch is optional.
It's easy enough to create a release branch, but merging back into dev and
master can sometimes be painful. I'm not s
Here is my reply from the previous thread:
> 1) There would be a period of time until a release is “frozen”.
>
> IMO there's no need for a freeze, branching should take care of any issue.
> I don't think a freeze would of solved any issue we're run into in the past.
>
The freeze would be the cut
> Changing the subject to make sure folks not interested in TDF also pay
> attention.
>
I find this thread hopping very confusing. Even more so then having a
discussion in a thread with a "wrong" title :-(
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I.
On Oct 26, 2014 7:57 AM, "Alex Harui" wrote:
>
> Changing the subject to make sure folks not interested in TDF also pay
> attention.
>
> For folks who haven’t been following closely, there’s been discussion on
> trying to find a more efficient way to do releases. In the past we cut a
> release ca
Changing the subject to make sure folks not interested in TDF also pay
attention.
For folks who haven’t been following closely, there’s been discussion on
trying to find a more efficient way to do releases. In the past we cut a
release candidate (RC) and start a vote but if issues are found, we h
d allow direct editing of
> the file on the site so that 3rd party content will show up immediately
> without having to go through a release process.
Created an issue in JIRA for this:
https://issues.apache.org/jira/browse/FLEX-34501
Justin
On 8/26/14 7:56 PM, "Justin Mclean" wrote:
>
>This is also one other subtle issue I've just released. If we don't use
>the standard release process, then as per CTR -1 counts as a veto
>effectually blocking a release. Do we want to do there?
Well, it blocks th
HI,
> Unless I get some support from others, we'll be doing it the way you want.
OK, thanks.
This is also one other subtle issue I've just released. If we don't use the
standard release process, then as per CTR -1 counts as a veto effectually
blocking a release. Do w
On 8/26/14 4:34 PM, "Justin Mclean" wrote:
>Hi,
>
>> Agreed, TDF might attract a new pool of developers. We are just
>> disagreeing on what the best way of attracting them is. I think trying
>>to
>> attracting them by asking them to do manual testing is not as attractive
>> as asking them to
Hi,
> Agreed, TDF might attract a new pool of developers. We are just
> disagreeing on what the best way of attracting them is. I think trying to
> attracting them by asking them to do manual testing is not as attractive
> as asking them to provide TDF fixes.
1. So manually testing is:
- compil
Hi,
> I know it seems clear to you, but other incubator folks disagree with you.
Two people suggesting you could possibly release it as snapshop is not exactly
the same thing as disagreeing with me.
> If the explorer.xml was not compiled in, flexicious's examples would be
> hooked up by now.
T
On 8/26/14 4:04 PM, "Justin Mclean" wrote:
>No, you can't announce / promote nightly build/snapshots [1].
>" Do not include any links on the project website that might encourage
>non-developers to download and use nightly builds, snapshots, release
>candidates, or any other similar package."
>
Hi,
> I think it would have been much more rewarding
> to the person offering the 3rd party links if we could have hooked him up
> yesterday.
I'm not sure that they are currently in a form that can be used in the
application and we would need to change the application to make it clear in the
a
d say the line is when we compile a swf with the code in the repo,
> >we
> >need to make an official release. If we are hot linking, i.e. we don't
> >have the source for an example, we don't need to go through the release
> >process. Same way as the Install
Hi,
> I would say the line is when we compile a swf with the code in the repo, we
> need to make an official release.
+1 to that.
> If we are hot linking, i.e. we don't have the source for an example, we
> don't need to go through the release
> process. Same way a
, not trying to find ways to avoid using it.
> We'll see what others think. I'd rather just save the time. I don't get
> why we need to have 3 people look at simple changes before they go on the
> site.
We're talking about code changes here, yes the application is simple, but that
doesn't mean that it's exempt from the release process and there are very good
reason to use that process.
Thanks,
Justin
1. http://www.apache.org/dev/release.html
l release. If we are hot linking, i.e. we don't
>have the source for an example, we don't need to go through the release
>process. Same way as the Installer. If we know that a dependency has
>changed, we just change it in the installer config xml and push the site.
>If we
rty component
> >developers. Because we want to hotlink to their examples and code
> >directly, we may not be able to 'build' a release from our side.
> >
> >I propose that we create a new thirdparty.xml and allow direct editing of
> >the file on the site so tha
gt; On 8/26/14 2:46 PM, "Justin Mclean" wrote:
>
> >>I don't see any reason to add process where process is not required
> >It's about community building.
> I'm not sure extra process invites community building.
> >
> >> we can save ti
hat we create a new thirdparty.xml and allow direct editing of
>the file on the site so that 3rd party content will show up immediately
>without having to go through a release process.
I'm not sure I understand your position. I think you are saying you only
want to push a compiled sour
es community building.
>
>> we can save time by not having to through the release process to fix
>>bugs
>> in the website version of TDF
>Can you spell out the process here.
Modify the landing page to give a proper label: "Daily Update", "Bleeding
Edge", &q
nd allow direct editing of
the file on the site so that 3rd party content will show up immediately
without having to go through a release process.
Thanks,
Om
On Tue, Aug 26, 2014 at 2:46 PM, Justin Mclean
wrote:
> Hi,
>
> > They said we could label the website version as a "dev
mmunity building.
> we can save time by not having to through the release process to fix bugs
> in the website version of TDF
Can you spell out the process here.
As I see it - benefits of using a voting process:
- PMC endorsement
- Legal angle covered (IP issues etc)
- Community engagement (t
or
"snapshot" (like Maven) does.
I don't see any reason to add process where process is not required so if
we can save time by not having to through the release process to fix bugs
in the website version of TDF, we should save time and do so. In fact, I
would argue it would give us b
Hi,
Forwarding to dev@ at Om and Alex's request (with a couple of very minor
edits). Please feel free to comment.
Justin
> From: Justin Mclean
> Subject: Reason for the release process
> Date: 26 August 2014 12:07:29 pm AEST
> To: priv...@flex.apache.org
>
> Hi,
>
Ok thnaks
-Message d'origine-
De : Justin Mclean [mailto:jus...@classsoftware.com]
Envoyé : samedi 15 mars 2014 00:12
À : dev@flex.apache.org
Objet : Re: Release Process
Hi,
> You mean 4.12.1 would be in the "release4.12.0" git branch ?
Yes.
> Or create a new rel
Hi,
> You mean 4.12.1 would be in the "release4.12.0" git branch ?
Yes.
> Or create a new release4.12.1 git branch ?
You could but no real need as current 4.12 is frozen as it was released.
> They are not referenced in the WIKI. Which script are useful?
Sorry it was the build directory not the i
urice
-Message d'origine-
De : Justin Mclean [mailto:jus...@classsoftware.com]
Envoyé : vendredi 14 mars 2014 23:19
À : dev@flex.apache.org
Objet : Re: Release Process
Hi,
If you wait a few weeks you may want to decide which changes you pull into the
the 4.12 branch.
In that cas
> and just applying step by step would result in a successful release ?
> https://cwiki.apache.org/confluence/display/FLEX/Release+Guide+for+the+SDK
It's up to date (part of the release process is to make sure it's up to date)
also take a look in the IDE directory I've adde
DK
Maurice
-Message d'origine-
De : Nicholas Kwiatkowski [mailto:nicho...@spoon.as]
Envoyé : vendredi 14 mars 2014 22:52
À : dev@flex.apache.org
Objet : Re: Release Process
All we have to do is have somebody package up a release and put it to a vote.
No different than a "regular
software.com]
> Envoyé : vendredi 14 mars 2014 22:38
> À : dev@flex.apache.org
> Objet : Re: Release Process
>
> Hi,
>
> You can have alpha and beta releases under Apache but I don't think it
> would help. If we do find a serious bug we can always fix it and make a
> point release eg 4.12.1 easily enough.
>
> Justin
>
he process.
Thanks,
Om
> Maurice
>
> -Message d'origine-
> De : Justin Mclean [mailto:jus...@classsoftware.com]
> Envoyé : vendredi 14 mars 2014 22:38
> À : dev@flex.apache.org
> Objet : Re: Release Process
>
> Hi,
>
> You can have alpha and beta releases
1 - 100 of 104 matches
Mail list logo
