You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Justin Mclean <ju...@classsoftware.com> on 2014/10/26 09:42:33 UTC
Release 1.2 of Tour De Flex
Hi,
After Squiggly is released I like to release Tour De Flex 1.2. [1] It has a couple of significant improvements including support for 3rd party components and (allmost) all examples now have a cleaner, more consistent look and feel. A couple of Squiggly examples have also been added. [2]
Can current committers/PMC members take a look at what currently is in develop and review/point out any issues? If no issue are raised in the next few days I'll make a release candidate and call a vote.
If there is anything people would like to see fixed or features added in this release please speak up now.
Thanks,
Justin
1. https://issues.apache.org/jira/browse/FLEX-34612
2. https://github.com/apache/flex-utilities/blob/develop/TourDeFlex/TourDeFlex3/RELEASE_NOTES
Re: Release 1.2 of Tour De Flex
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> A suggestion: why not cut a release branch
Done. Although given the minimal changes/few people working on the Tour De Flex project and stable state it is is in it's not a big issue either way.
Thanks,
justin
Re: Release 1.2 of Tour De Flex
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> > 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 cutting of the release branch. There needs to be a
grace period before that, as Harbs indicates, where a call goes out to
check in any and all changes that people want to be in the release. We are
currently in the 'grace period' for the 4.14 release, waiting for the iOS 7
skins and some other contributions.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Release 1.2 of Tour De Flex
Posted by Harbs <ha...@gmail.com>.
Thank you very much. I’ll read through these tomorrow.
On Oct 26, 2014, at 11:16 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> Can you give me any links on this? I’m not familiar enough with official policy.
>
>
> Try theres [1][2][3][4][5] + there's lot more.
>
> There was also a discussion recently where two RCs were voted on in a single thread. There was some confusion to which RC people voted one and if the last RC had 3 votes or not. Sorry I can't recall the project - this may of been it. [6]
>
> Re official policy see [7] but [8] and particularly [9] are also of interest here.
>
> Thanks,
> Justin
>
> 1.http://markmail.org/thread/cwrko3tvuyhebygy
> 2. http://markmail.org/thread/zjf52w6xb6h524jp
> 3.http://markmail.org/thread/kszzjwdf7atetl6u
> 4.http://markmail.org/thread/bohk4kknyjmd5xdd
> 5. http://markmail.org/thread/b5oc7fb5re5uorub
> 6. http://markmail.org/thread/wxcdhwtn5qriy7xk
> 7 http://www.apache.org/dev/release.html#approving-a-release
> 8. http://incubator.apache.org/guides/releasemanagement.html#best-practices-svn
> 9. http://incubator.apache.org/guides/releasemanagement.html#best-practice-reproducability
>
Re: Release 1.2 of Tour De Flex
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Can you give me any links on this? I’m not familiar enough with official policy.
Try theres [1][2][3][4][5] + there's lot more.
There was also a discussion recently where two RCs were voted on in a single thread. There was some confusion to which RC people voted one and if the last RC had 3 votes or not. Sorry I can't recall the project - this may of been it. [6]
Re official policy see [7] but [8] and particularly [9] are also of interest here.
Thanks,
Justin
1.http://markmail.org/thread/cwrko3tvuyhebygy
2. http://markmail.org/thread/zjf52w6xb6h524jp
3.http://markmail.org/thread/kszzjwdf7atetl6u
4.http://markmail.org/thread/bohk4kknyjmd5xdd
5. http://markmail.org/thread/b5oc7fb5re5uorub
6. http://markmail.org/thread/wxcdhwtn5qriy7xk
7 http://www.apache.org/dev/release.html#approving-a-release
8. http://incubator.apache.org/guides/releasemanagement.html#best-practices-svn
9. http://incubator.apache.org/guides/releasemanagement.html#best-practice-reproducability
Re: Release 1.2 of Tour De Flex
Posted by Harbs <ha...@gmail.com>.
Can you give me any links on this? I’m not familiar enough with official policy.
Thanks,
Harbs
On Oct 26, 2014, at 1:25 PM, Justin Mclean <ju...@classsoftware.com> wrote:
>> 3) A discussion/VOTE is opened at that point and kept open until the release is voted through.
>
> A vote can only be against a single RC / tag (see multiple comments on votes on incubator re match release with what's in version control and discussion around mutable git tags). Basically I not sure how that could work.
Re: Release 1.2 of Tour De Flex
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> 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.
> 3) A discussion/VOTE is opened at that point and kept open until the release is voted through.
A vote can only be against a single RC / tag (see multiple comments on votes on incubator re match release with what's in version control and discussion around mutable git tags). Basically I not sure how that could work.
Thanks,
Justin
Re: Release 1.2 of Tour De Flex
Posted by Harbs <ha...@gmail.com>.
This makes sense to me. Perhaps we should discuss, and document how to best go about ("no RC") releases?
It seems to me that there are two types of releases: Normal releases and “hot fix” releases. In the case of a normal release, I think there should be mechanism built in to encourage people to commit fixes prior to the release. I’m thinking something like this:
1) There would be a period of time until a release is “frozen”. 72 hours? Anyone working on something that should go into the release should commit their work to develop before that time is up.
2) Once the freeze goes into effect, a branch is made for release x.xx for xyz
3) A discussion/VOTE is opened at that point and kept open until the release is voted through. Any issues discovered should be corrected in the release branch. If they are applicable to future releases, the change should be applied to develop as well.
For hot fixes, the last release branch should probably be branched and we should have an expedited voting process.
Anything else? Are there complications that I’m ignoring/missing?
On Oct 26, 2014, at 11:37 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Justin,
>
> I applaud and would like to promote the new "no-RC" release procedure. I
> encourage all contributors (not only committers/PMC members) to look at the
> mentioned branch (develop) and check it as it were a release candidate!
> This way, if any issues are found, they can be fixed and tested without
> Justin having to call (and cancel) repeated RCs. Which will save all
> involved a lot of time.
>
> A suggestion: why not cut a release branch and have the testers work of
> that? That way development doesn't have to be frozen on 'develop', or -
> lacking a freeze - prevent 'develop' from becoming a moving target during
> testing, when new commits are made. Changes made on the release branch can
> be merged back to into 'develop' even during the release cycle. This is how
> the process was originally envisioned when we made the move to Git [1].
>
> On a personal note: the frequency of the utility releases is too high for
> me to actively participate in any of them while also contributing actual
> code to the project.
>
> EdB
>
> 1: http://nvie.com/posts/a-successful-git-branching-model/
>
>
>
> On Sunday, October 26, 2014, Justin Mclean <ju...@classsoftware.com> wrote:
>
>> Hi,
>>
>> After Squiggly is released I like to release Tour De Flex 1.2. [1] It has
>> a couple of significant improvements including support for 3rd party
>> components and (allmost) all examples now have a cleaner, more consistent
>> look and feel. A couple of Squiggly examples have also been added. [2]
>>
>> Can current committers/PMC members take a look at what currently is in
>> develop and review/point out any issues? If no issue are raised in the next
>> few days I'll make a release candidate and call a vote.
>>
>> If there is anything people would like to see fixed or features added in
>> this release please speak up now.
>>
>> Thanks,
>> Justin
>>
>> 1. https://issues.apache.org/jira/browse/FLEX-34612
>> 2.
>> https://github.com/apache/flex-utilities/blob/develop/TourDeFlex/TourDeFlex3/RELEASE_NOTES
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
Re: Release 1.2 of Tour De Flex
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Justin,
I applaud and would like to promote the new "no-RC" release procedure. I
encourage all contributors (not only committers/PMC members) to look at the
mentioned branch (develop) and check it as it were a release candidate!
This way, if any issues are found, they can be fixed and tested without
Justin having to call (and cancel) repeated RCs. Which will save all
involved a lot of time.
A suggestion: why not cut a release branch and have the testers work of
that? That way development doesn't have to be frozen on 'develop', or -
lacking a freeze - prevent 'develop' from becoming a moving target during
testing, when new commits are made. Changes made on the release branch can
be merged back to into 'develop' even during the release cycle. This is how
the process was originally envisioned when we made the move to Git [1].
On a personal note: the frequency of the utility releases is too high for
me to actively participate in any of them while also contributing actual
code to the project.
EdB
1: http://nvie.com/posts/a-successful-git-branching-model/
On Sunday, October 26, 2014, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
> After Squiggly is released I like to release Tour De Flex 1.2. [1] It has
> a couple of significant improvements including support for 3rd party
> components and (allmost) all examples now have a cleaner, more consistent
> look and feel. A couple of Squiggly examples have also been added. [2]
>
> Can current committers/PMC members take a look at what currently is in
> develop and review/point out any issues? If no issue are raised in the next
> few days I'll make a release candidate and call a vote.
>
> If there is anything people would like to see fixed or features added in
> this release please speak up now.
>
> Thanks,
> Justin
>
> 1. https://issues.apache.org/jira/browse/FLEX-34612
> 2.
> https://github.com/apache/flex-utilities/blob/develop/TourDeFlex/TourDeFlex3/RELEASE_NOTES
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Release 1.2 of Tour De Flex
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
If there no further feedback I'll make a release candidate and call a VOTE in two days. That given 5 days for people to review what is currently there.
Thanks,
Justin
Re: Release 1.2 of Tour De Flex
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Added to Tour De Flex and checked in to release branch. Modified warning slightly to also include "may not be Open Source".
Justin
Re: Release 1.2 of Tour De Flex
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> Agreed, that was my proposal for the Showcase.
Perhaps that needs to be in another thread?
> If you really have to go with yours I would take out the “for legal reasons”.
Done and checked into release branch.
Thanks,
Justin
Re: Release 1.2 of Tour De Flex
Posted by Alex Harui <ah...@adobe.com>.
On 10/27/14, 10:42 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> "The products and services listed on this page are provided for
>> information use only to our users. The Apache Directory™ PMC does not
>> endorse or recommend any of the products or services on this page."
>
>However not sure that the above wording works as it's not really a list
>of product or services but an example, component or a currently page with
>some information that links to an example or component.
Agreed, that was my proposal for the Showcase. My proposal for TDF was:
“Some examples include components that are developed outside of the Apache
Flex project and may have different license agreements. The Apache Flex™
PMC does not endorse or recommend any of those components."
>
>How about this text?
>
>This example or component has been developed by a 3rd party and is hosted
>outside of the Tour De Flex site and may contain links to non ASF sites.
>It's code may be under a license other than the Apache license so please
>check carefully before using it. Neither the ASF or the Apache Flex PMC
>can endorse or recommend using this example or component for legal
>reasons but you may still find it useful.
I think mine is shorter and more consistent with other disclaimers. If
you really have to go with yours I would take out the “for legal reasons”.
AFAICT, it isn’t so much a “you broke the law” issue, but rather, 1)
trying to ensure there isn’t corporate influence on Apache and 2) more
about tax treatment of the potential value of endorsements.
-Alex
Re: Release 1.2 of Tour De Flex
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> "The products and services listed on this page are provided for
> information use only to our users. The Apache Directory™ PMC does not
> endorse or recommend any of the products or services on this page."
However not sure that the above wording works as it's not really a list of product or services but an example, component or a currently page with some information that links to an example or component.
How about this text?
This example or component has been developed by a 3rd party and is hosted outside of the Tour De Flex site and may contain links to non ASF sites. It's code may be under a license other than the Apache license so please check carefully before using it. Neither the ASF or the Apache Flex PMC can endorse or recommend using this example or component for legal reasons but you may still find it useful.
I've made it a bit friendlier IMO we don't want to scare users or 3rd parties off but I think that still warns the use it's not our content.
As we have control of what goes in the XML file there there is some level of vetting by the PMC.
Thanks,
Justin
Re: Release 1.2 of Tour De Flex
Posted by Alex Harui <ah...@adobe.com>.
On 10/27/14, 5:52 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>On Mon, Oct 27, 2014 at 5:48 PM, Justin Mclean <ju...@classsoftware.com>
>wrote:
>
>>- There's a fine line in being seeing as supporting 3rd party products
>>and
>> being seen as promoting/endorsing them.
>Fair enough. I had similar thoughts as well. What would be an acceptable
>way to tell the world about these 3rd party components? Perhaps in the
>splash screen or TourDeFlex under 'Latest examples'? What about on the
>website?
I was going to reference our showcase as an example, then realized we
haven’t implemented the suggestion in this email from legal-discuss, which
it appears I never forwarded to dev@.
I didn’t find an official template to use. I did find Apache Directory’s
support page [2] using this:
"The products and services listed on this page are provided for
information use only to our users. The Apache Directory™ PMC does not
endorse or recommend any of the products or services on this page."
I think that we could use this for the showcase (swapping ‘Directory’ for
‘Flex’ of course).
For TDF, it might be sufficient to add something like the following to the
very bottom after the copyright and trademark notice:
“Some examples include components that are developed outside of the Apache
Flex project and may have different license agreements. The Apache Flex™
PMC does not endorse or recommend any of those components."
-Alex
[1]
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201312.mbox/%3c5
2B44448.9010002@shanecurcuru.org%3e
[2] https://directory.apache.org/commercial-support.html
Re: Release 1.2 of Tour De Flex
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Fair enough. I had similar thoughts as well.
I would add the persons name to CONTRIBUTORS if I know who they were, but having an user name as flexicious.com doesn't give me much to go on :-) Apache is about individual contribution not who we work for.
> What would be an acceptable way to tell the world about these 3rd party components?
They show up in Tour De Flex in their own area under "3rd party components".
> Perhaps in the splash screen or TourDeFlex under 'Latest examples'? What about on the
> website?
Tour De Flex does now have a welcome screen, but IMO no need to promote as I'm sure the 3rd parties will be on top of that for us :-)
Thanks,
Justin
Re: Release 1.2 of Tour De Flex
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Mon, Oct 27, 2014 at 5:48 PM, Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > Do we want to name the actual 3rd party components added to the Release
> > notes? Seems like that is a significant chunk of information missing.
>
>
> I decided not to mention them by name in the release notes and just state
> that 3rd party support was added as:
> - There's a fine line in being seeing as supporting 3rd party products and
> being seen as promoting/endorsing them.
> - The components in question are not part of the release but are hosted
> externally.
> - The 3rd party XML file is loaded at runtime so we can add (or remove)
> 3rd party components as required.
>
> Thanks,
> Justin
>
>
Fair enough. I had similar thoughts as well. What would be an acceptable
way to tell the world about these 3rd party components? Perhaps in the
splash screen or TourDeFlex under 'Latest examples'? What about on the
website?
Thanks,
Om
Re: Release 1.2 of Tour De Flex
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Do we want to name the actual 3rd party components added to the Release
> notes? Seems like that is a significant chunk of information missing.
I decided not to mention them by name in the release notes and just state that 3rd party support was added as:
- There's a fine line in being seeing as supporting 3rd party products and being seen as promoting/endorsing them.
- The components in question are not part of the release but are hosted externally.
- The 3rd party XML file is loaded at runtime so we can add (or remove) 3rd party components as required.
Thanks,
Justin
Re: Release 1.2 of Tour De Flex
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Mon, Oct 27, 2014 at 5:30 PM, Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > Did you fix the label for MaskedTextInput example?
>
> Yes - see JIRA / commits list emails.
>
>
Okay, I see it now. Thanks!
Do we want to name the actual 3rd party components added to the Release
notes? Seems like that is a significant chunk of information missing.
Thanks,
Om
> Thanks,
> Justin
>
Re: Release 1.2 of Tour De Flex
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Did you fix the label for MaskedTextInput example?
Yes - see JIRA / commits list emails.
Thanks,
Justin
Re: Release 1.2 of Tour De Flex
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Mon, Oct 27, 2014 at 5:22 PM, Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> Other than one example having an incorrect title (now fixed) is there any
> other feedback?
>
> Thanks,
> Justin
Did you fix the label for MaskedTextInput example?
Thanks,
Om
Re: Release 1.2 of Tour De Flex
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Other than one example having an incorrect title (now fixed) is there any other feedback?
Thanks,
Justin