You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Justin Mclean <ju...@classsoftware.com> on 2019/01/05 23:20:52 UTC
Official releases vs unreleased code
Hi,
Over the last few months I’ve run into 1/2 dozen podlings who are making and promoting releases to the wider community that contain unreleased code, and I’m a little surprised that they were unaware that this is not allowed. This also has come up in feedback received from the exit questionnaire.
In the release policy [3] it clearly states:
"Projects MUST direct outsiders towards official releases rather than raw source repositories, nightly builds, snapshots, release candidates, or any other similar packages.”
This has been discussed many times but these two legal JIRAs [1][2] spell it out quite clearly. And while these tickets refer to docker the same applies to any distribution mechanism.
In short “It is appropriate to distribute official releases through downstream channels, but inappropriate to distribute unreleased materials through them.”
So if your projects is using docker, PiPY, GitHub releases, npm or any other ways of distribution please make sure that the wider community is only pointed at official release and the best way to do this is not to publish unreleased code on those platforms. Ask yourself is someone outside of the project likely to use this and if the answer is yes then reconsider how you are using that distribution channel and make sure it only contains official releases.
Thanks,
Justin
1. https://issues.apache.org/jira/browse/LEGAL-270
2. https://issues.apache.org/jira/browse/LEGAL-427
3. http://www.apache.org/legal/release-policy.html#publication
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Official releases vs unreleased code
Posted by Justin Mclean <jm...@apache.org>.
Hi,
All good, thanks for dealing with this quickly.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@doris.apache.org
For additional commands, e-mail: dev-help@doris.apache.org
Re: Official releases vs unreleased code
Posted by "Li,De(BDG)" <li...@baidu.com>.
Hi Justin,
Thank you to remind us, and I removed [2][4] and [5], and marked Palo
0.8.1-beta and Palo 0.8.0-beta as non-apache pre-release, which made
before entered incubation.
Best Regards,
Reed
On 2019/1/31 上午4:39， "Justin Mclean" <jm...@apache.org> wrote:
>Hi,
>
>> [4] 2018-10-27 Made a tag 0.8.2.1
>> [5] 2018-12-11 Made a tag 0.9.0-rc01
>
>Tags are probably OK but these also show up on the release page [1] which
>is problematic. There is no clear indication that there are not Apache
>releases especially releases 4 and 5.
>
>> I’m not sure that if [2] and [4] are non-Apache releases, if they are, I
>> can remove them.
>
>As far as I can can see they are all non Apache releases as they have not
>been endorsed by the PPMC and the IPMC. Please remove any that have been
>made after you entered incubation and clear mark any before that as not
>offical releases.
>
>Thanks,
>Justin
>
>1. https://github.com/apache/incubator-doris/releases
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@doris.apache.org
>For additional commands, e-mail: dev-help@doris.apache.org
>
Re: Official releases vs unreleased code
Posted by Justin Mclean <jm...@apache.org>.
Hi,
> [4] 2018-10-27 Made a tag 0.8.2.1
> [5] 2018-12-11 Made a tag 0.9.0-rc01
Tags are probably OK but these also show up on the release page [1] which is problematic. There is no clear indication that there are not Apache releases especially releases 4 and 5.
> I’m not sure that if [2] and [4] are non-Apache releases, if they are, I
> can remove them.
As far as I can can see they are all non Apache releases as they have not been endorsed by the PPMC and the IPMC. Please remove any that have been made after you entered incubation and clear mark any before that as not offical releases.
Thanks,
Justin
1. https://github.com/apache/incubator-doris/releases
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@doris.apache.org
For additional commands, e-mail: dev-help@doris.apache.org
Re: Official releases vs unreleased code
Posted by "Li,De(BDG)" <li...@baidu.com>.
Hi Dave and Willem,
We have one release[2] and one tag[4] in GitHub made after entering
incubation.
The detail as following:
[1] 2018-07-18 Project enters incubation;
[2] 2018-08-25 Github release 0.8.2.
[3] 2018-08-30 Migration of Palo to Apache Github Organization is Done.
[4] 2018-10-27 Made a tag 0.8.2.1
[5] 2018-12-11 Made a tag 0.9.0-rc01 and now still pending to wait voting
in Apache community.
I’m not sure that if [2] and [4] are non-Apache releases, if they are, I
can remove them.
Best Regards,
Reed
On 2019/1/9 上午11:11， "Dave Fisher" <da...@comcast.net> wrote:
>Yes! Please review. There are no bad questions. Please ask to clarify any
>doubts!
>
>I have one question. Have there been any non-Apache releases since
>Incubation started?
>
>Regards,
>Dave
>
>Sent from my iPhone
>
>> On Jan 8, 2019, at 7:06 PM, Willem Jiang <wi...@gmail.com> wrote:
>>
>> Hi Team，
>>
>> I'm not sure if you are aware the official release and unreleased code
>> in Apache Incubator.
>> Please take some time read through the code and let me know what you
>>think.
>>
>> Willem Jiang
>>
>> Twitter: willemjiang
>> Weibo: 姜宁willem
>>
>>
>> ---------- Forwarded message ---------
>> From: Justin Mclean <ju...@classsoftware.com>
>> Date: Sun, Jan 6, 2019 at 7:21 AM
>> Subject: Official releases vs unreleased code
>> To: <ge...@incubator.apache.org>
>>
>>
>> Hi,
>>
>> Over the last few months I’ve run into 1/2 dozen podlings who are
>> making and promoting releases to the wider community that contain
>> unreleased code, and I’m a little surprised that they were unaware
>> that this is not allowed. This also has come up in feedback received
>> from the exit questionnaire.
>>
>> In the release policy [3] it clearly states:
>> "Projects MUST direct outsiders towards official releases rather than
>> raw source repositories, nightly builds, snapshots, release
>> candidates, or any other similar packages.”
>>
>> This has been discussed many times but these two legal JIRAs [1][2]
>> spell it out quite clearly. And while these tickets refer to docker
>> the same applies to any distribution mechanism.
>>
>> In short “It is appropriate to distribute official releases through
>> downstream channels, but inappropriate to distribute unreleased
>> materials through them.”
>>
>> So if your projects is using docker, PiPY, GitHub releases, npm or any
>> other ways of distribution please make sure that the wider community
>> is only pointed at official release and the best way to do this is not
>> to publish unreleased code on those platforms. Ask yourself is someone
>> outside of the project likely to use this and if the answer is yes
>> then reconsider how you are using that distribution channel and make
>> sure it only contains official releases.
>>
>> Thanks,
>> Justin
>>
>> 1. https://issues.apache.org/jira/browse/LEGAL-270
>> 2. https://issues.apache.org/jira/browse/LEGAL-427
>> 3. http://www.apache.org/legal/release-policy.html#publication
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@doris.apache.org
>> For additional commands, e-mail: dev-help@doris.apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@doris.apache.org
>For additional commands, e-mail: dev-help@doris.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@doris.apache.org
For additional commands, e-mail: dev-help@doris.apache.org
Re: Official releases vs unreleased code
Posted by Dave Fisher <da...@comcast.net>.
Yes! Please review. There are no bad questions. Please ask to clarify any doubts!
I have one question. Have there been any non-Apache releases since Incubation started?
Regards,
Dave
Sent from my iPhone
> On Jan 8, 2019, at 7:06 PM, Willem Jiang <wi...@gmail.com> wrote:
>
> Hi Team，
>
> I'm not sure if you are aware the official release and unreleased code
> in Apache Incubator.
> Please take some time read through the code and let me know what you think.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
> ---------- Forwarded message ---------
> From: Justin Mclean <ju...@classsoftware.com>
> Date: Sun, Jan 6, 2019 at 7:21 AM
> Subject: Official releases vs unreleased code
> To: <ge...@incubator.apache.org>
>
>
> Hi,
>
> Over the last few months I’ve run into 1/2 dozen podlings who are
> making and promoting releases to the wider community that contain
> unreleased code, and I’m a little surprised that they were unaware
> that this is not allowed. This also has come up in feedback received
> from the exit questionnaire.
>
> In the release policy [3] it clearly states:
> "Projects MUST direct outsiders towards official releases rather than
> raw source repositories, nightly builds, snapshots, release
> candidates, or any other similar packages.”
>
> This has been discussed many times but these two legal JIRAs [1][2]
> spell it out quite clearly. And while these tickets refer to docker
> the same applies to any distribution mechanism.
>
> In short “It is appropriate to distribute official releases through
> downstream channels, but inappropriate to distribute unreleased
> materials through them.”
>
> So if your projects is using docker, PiPY, GitHub releases, npm or any
> other ways of distribution please make sure that the wider community
> is only pointed at official release and the best way to do this is not
> to publish unreleased code on those platforms. Ask yourself is someone
> outside of the project likely to use this and if the answer is yes
> then reconsider how you are using that distribution channel and make
> sure it only contains official releases.
>
> Thanks,
> Justin
>
> 1. https://issues.apache.org/jira/browse/LEGAL-270
> 2. https://issues.apache.org/jira/browse/LEGAL-427
> 3. http://www.apache.org/legal/release-policy.html#publication
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@doris.apache.org
> For additional commands, e-mail: dev-help@doris.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@doris.apache.org
For additional commands, e-mail: dev-help@doris.apache.org
Re: Official releases vs unreleased code
Posted by 申远 <sh...@gmail.com>.
It took me a while to read the related JIRA issuse, emails and policies, and I think the following is allowed in legal and Apache brand management opinions:
Publish binary artifacts through npm, cocoapods and jcenter(maven), which are basically industry standard binary downstream/distribution channel for JS, iOS and Android developers.
The following is under consideration:
Now, one of Weex PPMC members build binary artifacts and publish to the above distribution channels using the same source code as the formal Apache release. But this binary distribution is not voted as the corresponding source code is voted yet. Do we need to vote the binary artifacts? If a vote is needed, what and how the PPMC members check the binary artifacts?
The following is FORBIDDEN:
Publish unreleased codes/artifacts in any binary channel even if it is called alpha/beta release under the name of Apache Weex/Weex PPMC members. It looks like we need to cancel the weex weekly publishing permanently as it is against the Apache rules.
> 在 2019年1月9日，11:06，Willem Jiang <wi...@gmail.com> 写道：
>
> Hi Team，
>
> I'm not sure if you are aware the official release and unreleased code
> in Apache Incubator.
> Please take some time read through the code and let me know what you think.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
> ---------- Forwarded message ---------
> From: Justin Mclean <ju...@classsoftware.com>
> Date: Sun, Jan 6, 2019 at 7:21 AM
> Subject: Official releases vs unreleased code
> To: <ge...@incubator.apache.org>
>
>
> Hi,
>
> Over the last few months I’ve run into 1/2 dozen podlings who are
> making and promoting releases to the wider community that contain
> unreleased code, and I’m a little surprised that they were unaware
> that this is not allowed. This also has come up in feedback received
> from the exit questionnaire.
>
> In the release policy [3] it clearly states:
> "Projects MUST direct outsiders towards official releases rather than
> raw source repositories, nightly builds, snapshots, release
> candidates, or any other similar packages.”
>
> This has been discussed many times but these two legal JIRAs [1][2]
> spell it out quite clearly. And while these tickets refer to docker
> the same applies to any distribution mechanism.
>
> In short “It is appropriate to distribute official releases through
> downstream channels, but inappropriate to distribute unreleased
> materials through them.”
>
> So if your projects is using docker, PiPY, GitHub releases, npm or any
> other ways of distribution please make sure that the wider community
> is only pointed at official release and the best way to do this is not
> to publish unreleased code on those platforms. Ask yourself is someone
> outside of the project likely to use this and if the answer is yes
> then reconsider how you are using that distribution channel and make
> sure it only contains official releases.
>
> Thanks,
> Justin
>
> 1. https://issues.apache.org/jira/browse/LEGAL-270
> 2. https://issues.apache.org/jira/browse/LEGAL-427
> 3. http://www.apache.org/legal/release-policy.html#publication
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
Fwd: Official releases vs unreleased code
Posted by Willem Jiang <wi...@gmail.com>.
Hi Team，
I'm not sure if you are aware the official release and unreleased code
in Apache Incubator.
Please take some time read through the code and let me know what you think.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
---------- Forwarded message ---------
From: Justin Mclean <ju...@classsoftware.com>
Date: Sun, Jan 6, 2019 at 7:21 AM
Subject: Official releases vs unreleased code
To: <ge...@incubator.apache.org>
Hi,
Over the last few months I’ve run into 1/2 dozen podlings who are
making and promoting releases to the wider community that contain
unreleased code, and I’m a little surprised that they were unaware
that this is not allowed. This also has come up in feedback received
from the exit questionnaire.
In the release policy [3] it clearly states:
"Projects MUST direct outsiders towards official releases rather than
raw source repositories, nightly builds, snapshots, release
candidates, or any other similar packages.”
This has been discussed many times but these two legal JIRAs [1][2]
spell it out quite clearly. And while these tickets refer to docker
the same applies to any distribution mechanism.
In short “It is appropriate to distribute official releases through
downstream channels, but inappropriate to distribute unreleased
materials through them.”
So if your projects is using docker, PiPY, GitHub releases, npm or any
other ways of distribution please make sure that the wider community
is only pointed at official release and the best way to do this is not
to publish unreleased code on those platforms. Ask yourself is someone
outside of the project likely to use this and if the answer is yes
then reconsider how you are using that distribution channel and make
sure it only contains official releases.
Thanks,
Justin
1. https://issues.apache.org/jira/browse/LEGAL-270
2. https://issues.apache.org/jira/browse/LEGAL-427
3. http://www.apache.org/legal/release-policy.html#publication
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@doris.apache.org
For additional commands, e-mail: dev-help@doris.apache.org
Re: Official releases vs unreleased code
Posted by Mark Thomas <ma...@apache.org>.
On 07/01/2019 12:05, Geertjan Wielenga wrote:
> So, just to be clear what this means in the context of Apache NetBeans.
>
> Here's two different scenarios that relate to this:
>
> 1. CoolBeans (coolbeans.xyz) is a distribution of Apache NetBeans, with the
> difference that it includes the 'enterprise' cluster (i.e., Jakarta/Java EE
> features) of Apache NetBeans, which we have not yet released. We are
> working to release this as part of our upcoming release and have several
> licensing issues remaining. However, since CoolBeans is not distributed by
> Apache, CoolBeans is not constrained by Apache's licensing concerns.
>
> Reading Justin's e-mail, I interpret him to state that it is not allowed to
> promote releases to the wider community that contain not released code,
> i.e., on the Apache NetBeans webpage, we cannot promote CoolBeans, on
> Apache NetBeans Twitter, we cannot promote CoolBeans, on the Apache
> NetBeans mailing lists, we cannot promote CoolBeans.
>
> Is this interpretation correct?
I would suggest reading "promote" in this context as "advertise as an
official ASF release" rather than "make people aware it exists".
Scenario 1 is a different issue. Coolbeans is a non-ASF product. That
makes it more of a branding / community issue than one of release policy.
Generally, projects don't promote down stream releases. Doing so creates
a risk of the ASF being viewed as biased (in favour of the organisation
producing the downstream release) rather than independent.
That said, if the community views it is in the best interest of the
community to promote Coolbeans then the community can do so. The
expectation is that the community would be equally happy to promote any
similar downstream project. If there are criteria about what the
community is and is not willing to promote then those criteria should be
(publicly) documented up front.
> 2. Even though we have not released the 'enterprise' cluster, we do have
> plugins from before we were an Apache project for Java/Jakarta EE features.
> These are available from a plugin portal and are built from the the same
> code as is found in the Apache NetBeans GitHub, though created from before
> that code was at Apache.
>
> Can we promote these plugins?
Again, as non-ASF releases "make people aware they exist" is fine (same
caveats as above) but "advertise them as official ASF releases" then no.
Generally, I would only expect to see official ASF releases on:
- announcement e-mails from the project
- project main download page
- etc.
HTH,
Mark
>
> Thanks,
>
> Gj
>
>
>
>
>
> On Sun, Jan 6, 2019 at 12:21 AM Justin Mclean <ju...@classsoftware.com>
> wrote:
>
>> Hi,
>>
>> Over the last few months I’ve run into 1/2 dozen podlings who are making
>> and promoting releases to the wider community that contain unreleased code,
>> and I’m a little surprised that they were unaware that this is not allowed.
>> This also has come up in feedback received from the exit questionnaire.
>>
>> In the release policy [3] it clearly states:
>> "Projects MUST direct outsiders towards official releases rather than raw
>> source repositories, nightly builds, snapshots, release candidates, or any
>> other similar packages.”
>>
>> This has been discussed many times but these two legal JIRAs [1][2] spell
>> it out quite clearly. And while these tickets refer to docker the same
>> applies to any distribution mechanism.
>>
>> In short “It is appropriate to distribute official releases through
>> downstream channels, but inappropriate to distribute unreleased materials
>> through them.”
>>
>> So if your projects is using docker, PiPY, GitHub releases, npm or any
>> other ways of distribution please make sure that the wider community is
>> only pointed at official release and the best way to do this is not to
>> publish unreleased code on those platforms. Ask yourself is someone outside
>> of the project likely to use this and if the answer is yes then reconsider
>> how you are using that distribution channel and make sure it only contains
>> official releases.
>>
>> Thanks,
>> Justin
>>
>> 1. https://issues.apache.org/jira/browse/LEGAL-270
>> 2. https://issues.apache.org/jira/browse/LEGAL-427
>> 3. http://www.apache.org/legal/release-policy.html#publication
>> ---------------------------------------------------------------------
>> 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: Official releases vs unreleased code
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
So, just to be clear what this means in the context of Apache NetBeans.
Here's two different scenarios that relate to this:
1. CoolBeans (coolbeans.xyz) is a distribution of Apache NetBeans, with the
difference that it includes the 'enterprise' cluster (i.e., Jakarta/Java EE
features) of Apache NetBeans, which we have not yet released. We are
working to release this as part of our upcoming release and have several
licensing issues remaining. However, since CoolBeans is not distributed by
Apache, CoolBeans is not constrained by Apache's licensing concerns.
Reading Justin's e-mail, I interpret him to state that it is not allowed to
promote releases to the wider community that contain not released code,
i.e., on the Apache NetBeans webpage, we cannot promote CoolBeans, on
Apache NetBeans Twitter, we cannot promote CoolBeans, on the Apache
NetBeans mailing lists, we cannot promote CoolBeans.
Is this interpretation correct?
2. Even though we have not released the 'enterprise' cluster, we do have
plugins from before we were an Apache project for Java/Jakarta EE features.
These are available from a plugin portal and are built from the the same
code as is found in the Apache NetBeans GitHub, though created from before
that code was at Apache.
Can we promote these plugins?
Thanks,
Gj
On Sun, Jan 6, 2019 at 12:21 AM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> Over the last few months I’ve run into 1/2 dozen podlings who are making
> and promoting releases to the wider community that contain unreleased code,
> and I’m a little surprised that they were unaware that this is not allowed.
> This also has come up in feedback received from the exit questionnaire.
>
> In the release policy [3] it clearly states:
> "Projects MUST direct outsiders towards official releases rather than raw
> source repositories, nightly builds, snapshots, release candidates, or any
> other similar packages.”
>
> This has been discussed many times but these two legal JIRAs [1][2] spell
> it out quite clearly. And while these tickets refer to docker the same
> applies to any distribution mechanism.
>
> In short “It is appropriate to distribute official releases through
> downstream channels, but inappropriate to distribute unreleased materials
> through them.”
>
> So if your projects is using docker, PiPY, GitHub releases, npm or any
> other ways of distribution please make sure that the wider community is
> only pointed at official release and the best way to do this is not to
> publish unreleased code on those platforms. Ask yourself is someone outside
> of the project likely to use this and if the answer is yes then reconsider
> how you are using that distribution channel and make sure it only contains
> official releases.
>
> Thanks,
> Justin
>
> 1. https://issues.apache.org/jira/browse/LEGAL-270
> 2. https://issues.apache.org/jira/browse/LEGAL-427
> 3. http://www.apache.org/legal/release-policy.html#publication
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Official releases vs unreleased code
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
A quick scan of some new podlings, has found several more that are not following the correct release process and that have been continuing to make unapproved releases after they have entered incubation.
Just a reminder to mentors that incubating projects can not make releases or provide releases (including binary releases) to the general public without approval of the IPMC.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Fwd: Official releases vs unreleased code
Posted by Willem Jiang <wi...@gmail.com>.
Hi Team，
I'm not sure if you are aware the official release and unreleased code
in Apache Incubator.
Please take some time read through the code and let me know what you think.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
---------- Forwarded message ---------
From: Justin Mclean <ju...@classsoftware.com>
Date: Sun, Jan 6, 2019 at 7:21 AM
Subject: Official releases vs unreleased code
To: <ge...@incubator.apache.org>
Hi,
Over the last few months I’ve run into 1/2 dozen podlings who are
making and promoting releases to the wider community that contain
unreleased code, and I’m a little surprised that they were unaware
that this is not allowed. This also has come up in feedback received
from the exit questionnaire.
In the release policy [3] it clearly states:
"Projects MUST direct outsiders towards official releases rather than
raw source repositories, nightly builds, snapshots, release
candidates, or any other similar packages.”
This has been discussed many times but these two legal JIRAs [1][2]
spell it out quite clearly. And while these tickets refer to docker
the same applies to any distribution mechanism.
In short “It is appropriate to distribute official releases through
downstream channels, but inappropriate to distribute unreleased
materials through them.”
So if your projects is using docker, PiPY, GitHub releases, npm or any
other ways of distribution please make sure that the wider community
is only pointed at official release and the best way to do this is not
to publish unreleased code on those platforms. Ask yourself is someone
outside of the project likely to use this and if the answer is yes
then reconsider how you are using that distribution channel and make
sure it only contains official releases.
Thanks,
Justin
1. https://issues.apache.org/jira/browse/LEGAL-270
2. https://issues.apache.org/jira/browse/LEGAL-427
3. http://www.apache.org/legal/release-policy.html#publication
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Fwd: Official releases vs unreleased code
Posted by Willem Jiang <wi...@gmail.com>.
Hi Team，
I'm not sure if you are aware the official release and unreleased code
in Apache Incubator.
Please take some time read through the code and let me know what you think.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
---------- Forwarded message ---------
From: Justin Mclean <ju...@classsoftware.com>
Date: Sun, Jan 6, 2019 at 7:21 AM
Subject: Official releases vs unreleased code
To: <ge...@incubator.apache.org>
Hi,
Over the last few months I’ve run into 1/2 dozen podlings who are
making and promoting releases to the wider community that contain
unreleased code, and I’m a little surprised that they were unaware
that this is not allowed. This also has come up in feedback received
from the exit questionnaire.
In the release policy [3] it clearly states:
"Projects MUST direct outsiders towards official releases rather than
raw source repositories, nightly builds, snapshots, release
candidates, or any other similar packages.”
This has been discussed many times but these two legal JIRAs [1][2]
spell it out quite clearly. And while these tickets refer to docker
the same applies to any distribution mechanism.
In short “It is appropriate to distribute official releases through
downstream channels, but inappropriate to distribute unreleased
materials through them.”
So if your projects is using docker, PiPY, GitHub releases, npm or any
other ways of distribution please make sure that the wider community
is only pointed at official release and the best way to do this is not
to publish unreleased code on those platforms. Ask yourself is someone
outside of the project likely to use this and if the answer is yes
then reconsider how you are using that distribution channel and make
sure it only contains official releases.
Thanks,
Justin
1. https://issues.apache.org/jira/browse/LEGAL-270
2. https://issues.apache.org/jira/browse/LEGAL-427
3. http://www.apache.org/legal/release-policy.html#publication
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org