You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Alex Harui <ah...@adobe.com> on 2014/08/25 18:51:56 UTC
Websites, WebApps, and Release Policy
Hi Incubator Folks,
My understanding is that changes to a website like flex.a.o don't require
a release vote, even though one could consider and html file pushed to the
site as publishing source beyond the group that owns it.
But what about web apps? Apache Flex is designed for creating web apps
made from source code that is compiled into a SWF.
Today, Apache Flex announced the release of Tour De Flex. The source code
is in one of our git repos, the source package is up on dist.apache.org,
and a compiled version of the source is on flex.a.o here:
http://flex.apache.org/tourdeflex/explorer.html
Users are playing with the app at that link and reporting bugs. I'm
wondering: can we modify the source with a bug fix and post the modified
source and compiled results on flex.a.o without a release vote? Tour De
Flex is potentially different from most web apps because its job is to
show you the source code behind the scenes. Most web apps can be
published without their source.
Also, can we make other modifications? One user found that a link was
broken and we fixed it by copying an asset to where the source said the
link was. Therefore what is on flex.a.o right now is no longer the
compiled results of the source.
Thanks,
-Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Websites, WebApps, and Release Policy
Posted by Branko Čibej <br...@apache.org>.
On 26.08.2014 00:24, Justin Mclean wrote:
> Hi,
>
>> This strikes me very similar to providing access to daily SNAPSHOT binary
>> artifacts. I would argue that labeling it appropriately is all you
>> need.
> Except that is this case the intended audience of the application is users.
Bloodhound has maintained two VMs that host publicly available
development snapshots since it was a podling, and still does today, more
than a year after it graduated. The situation is exactly the same; the
snapshots are clearly marked as "development work in progress", the
sources of the running instances are freely available from SVN to anyone
with a web browser. There has never been any confusion as to whether
these snapshots are an ASF Release or not.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Websites, WebApps, and Release Policy
Posted by Roman Shaposhnik <rv...@apache.org>.
On Mon, Aug 25, 2014 at 3:24 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> This strikes me very similar to providing access to daily SNAPSHOT binary
>> artifacts. I would argue that labeling it appropriately is all you
>> need.
> Except that is this case the intended audience of the application is users.
I see no difference between the two cases. Regardless of who the target
audience is SNAPSHOT is a SNAPSHOT is a SNAPSHOT. Look at it this
way: there are *tons* of users depending on SNAPSHOT Maven artifacts
of various Apache projects.
>> After all, if you're pushing updates it means that something that used to work yesterday
>> could stop working today.
> That's generally not the case here, we are publishing compiled code that runs in the flash player VM.
I was trying to make a general point that regardless of a technology,
if I come to the same website clearly labeled as '1.0 release'
and get different results -- I'd be unpleasantly surprised. There's a reason
Google labels things as 'beta'.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Websites, WebApps, and Release Policy
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> This strikes me very similar to providing access to daily SNAPSHOT binary
> artifacts. I would argue that labeling it appropriately is all you
> need.
Except that is this case the intended audience of the application is users.
> After all, if you're pushing updates it means that something that used to work yesterday
> could stop working today.
That's generally not the case here, we are publishing compiled code that runs in the flash player VM.
Thanks,
Justin
Re: Websites, WebApps, and Release Policy
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Are you addressing me personally or Roman or the incubator in general?
Was sent to general@ so the content of them is for the incubator in general, the emails were not personally addressed. But if it helps my second email was to clarify / add to Roman's comments.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Websites, WebApps, and Release Policy
Posted by Alex Harui <ah...@adobe.com>.
Hi Justin,
Are you addressing me personally or Roman or the incubator in general?
-Alex
On 8/25/14 3:21 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>The whole point point of the release process is to:
>1. Have legal overview by the PMC
>2. Engage and involve the community
>
>Why would we want to avoid either? As [1] says "Under no circumstances
>are unapproved builds a substitute for releases. If this policy seems
>inconvenient, then release more often."
>
>I'd also note also at [1]:
>"Deviations from this policy may have an adverse effect on the legal
>shield's effectiveness, or the insurance premiums Apache pays to protect
>officers and directors, so are strongly discouraged without prior,
>explicit board approval."
>
>Thanks,
>Justin
>
>1. http://www.apache.org/dev/release.html
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Websites, WebApps, and Release Policy
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
The whole point point of the release process is to:
1. Have legal overview by the PMC
2. Engage and involve the community
Why would we want to avoid either? As [1] says "Under no circumstances are unapproved builds a substitute for releases. If this policy seems inconvenient, then release more often."
I'd also note also at [1]:
"Deviations from this policy may have an adverse effect on the legal shield's effectiveness, or the insurance premiums Apache pays to protect officers and directors, so are strongly discouraged without prior, explicit board approval."
Thanks,
Justin
1. http://www.apache.org/dev/release.html
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Websites, WebApps, and Release Policy
Posted by Roman Shaposhnik <rv...@apache.org>.
On Mon, Aug 25, 2014 at 9:51 AM, Alex Harui <ah...@adobe.com> wrote:
> Hi Incubator Folks,
>
> My understanding is that changes to a website like flex.a.o don't require
> a release vote, even though one could consider and html file pushed to the
> site as publishing source beyond the group that owns it.
>
> But what about web apps? Apache Flex is designed for creating web apps
> made from source code that is compiled into a SWF.
>
> Today, Apache Flex announced the release of Tour De Flex. The source code
> is in one of our git repos, the source package is up on dist.apache.org,
> and a compiled version of the source is on flex.a.o here:
> http://flex.apache.org/tourdeflex/explorer.html
>
> Users are playing with the app at that link and reporting bugs. I'm
> wondering: can we modify the source with a bug fix and post the modified
> source and compiled results on flex.a.o without a release vote? Tour De
> Flex is potentially different from most web apps because its job is to
> show you the source code behind the scenes. Most web apps can be
> published without their source.
>
> Also, can we make other modifications? One user found that a link was
> broken and we fixed it by copying an asset to where the source said the
> link was. Therefore what is on flex.a.o right now is no longer the
> compiled results of the source.
This strikes me very similar to providing access to daily SNAPSHOT binary
artifacts. I would argue that labeling it appropriately is all you
need. In fact,
clearly labeling it would actually benefit your customers. After all, if you're
pushing updates it means that something that used to work yesterday
could stop working today. Personally, I find it very frustrating when this
happens on something that is clearly labeled as an immutable release.
Long story short, I guess if you labeled it something like:
"Apache Flex Tour De Flex Component Explorer Daily Update XXX"
instead of ""Apache Flex Tour De Flex Component Explorer 1.0"
I'd see no issues at all.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org