flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OmPrakash Muppirala <bigosma...@gmail.com>
Subject Re: Draft TourDeFlex announcement
Date Sat, 23 Aug 2014 07:10:59 GMT
We had a big discussion about this when we released the first version of
the Installer badge, installer config xml, etc. which goes on the website
as well.  You both might want to refresh on that thread before taking it to

In the meantime, I have couple of spare hours tonight and I want to make it
productive.  I am going to go with the RC3 bits to avoid any further


On Fri, Aug 22, 2014 at 11:47 PM, Justin Mclean <justin@classsoftware.com>

> Hi,
> > Might be a good question for general@incubator.  Mind if I ask there?
> Ask away.  But I think we should set a good example here and not try and
> get around the rules.
> > I'm all for faster release cycles.  I think it is 30 minutes minimum to
> > validate the TDF RC.
> It not really that complex to validate it IMO. And if we release often
> there well be less changes between versions and as it really multiple small
> applications you have a good idea of which ones you need to look at and
> which you can ignore.
> > Given the potentially high traffic and profile TDF
> > might get, we might be tempted to immediately fix any problem reported.
> There is no need to fix every issue immediately, we just need to
> acknowledge the issue (like in JIRA for instance), hopefully someone will
> fix it, and it can be released when we make the next release. Exactly the
> same situation as the SDK, it's not like that is 100% bug free (or we would
> have no open JIRAs)
> > Doing daily releases would be a little too fast for me.
> I don't think we need daily releases and voting periods will overlap
> probably making it very confusing. But if enough people show interest and
> contribute examples I could see a release a month.
> > Only successful builds would get pushed.
> Which can still be non functioning, should we ship everything just because
> it compiles?
> Thanks,
> Justin

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