You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@juneau.apache.org by James Bognar <ja...@salesforce.com> on 2016/09/30 16:29:30 UTC
Juneau new release guidelines.
New release guidelines are finished:
<goog_1805653564>
https://cwiki.apache.org/confluence/display/JUNEAU/New+release+guidelines
I'm ready to start a vote for juneau-6.0.0-incubating-RC1.
--
James Bognar
Re: Juneau new release guidelines.
Posted by Stian Soiland-Reyes <st...@apache.org>.
I think instead of multiple RELEASE-NOTES (which sounds like they will
easily be forgotten about) I would have a look at using
https://maven.apache.org/plugins/maven-changes-plugin/usage.html
to add the jira report - either just to the web site (and link to it
from the README) or using mvn changes:announcement-generate and then
copy from target/*something.txt to RELEASE-NOTES.txt
On 1 October 2016 at 16:09, James Bognar <ja...@salesforce.com> wrote:
> Hi John,
>
> Much of the credit goes to Stian who pointed me to the Taverna instructions
> from where I pulled much of the information:
> https://taverna.incubator.apache.org/community
>
> I spent a lot of time just trying to get the formatting right in
> Confluence. It's got a nice interface, but it's really buggy around
> formatting. Sometimes I would do something to cause the formatting on half
> the page to get messed up, and undo wouldn't fix it. Even now it looks
> fine on Chrome/Firefox/Safari, but the fonts are messed up on
> Safari-mobile. So be careful about that if you make any updates to the
> page.
>
>>- You may want to set push to false when doing a release. There's still a lot
> of discussion out there, but it may be easier to manage a release off
>>of a fork rather than the main repo (and push to the main repo once the release
> is done). There's trade offs either way.
>>- By not pushing, you eliminate the need to do an RC build as well.
>
> Using a fork sounds good to me. I'm still not too familiar with Git. Can
> you point me to an example of the instructions for doing so? (or simply
> update the doc?) I've never tried creating or merging forks (even though I
> know that's what Git is supposedly best at).
>
>>- It would be great if release notes could come out of JIRA rather than
>>being checked in.
>
> Agreed. Do you know how to do that from a command line (create JIRA
> versions, generate release notes, etc...)? If not, I can figure it out.
>
>> - The vote/discuss emails confuse me. Where did that come from? The most
>> I ever see (or expect to see) is a heads up style email saying someone is
>> thinking about cutting a release.
>
> That was based on the instructions from Taverna. Feel free to modify the
> templates.
>
>> I think we're also missing the DISCLAIMER as well, indicating that this
> is a project under incubation.
> In the email to general@incubator?
>
> Thanks John!
>
>
>
>
> On Fri, Sep 30, 2016 at 9:58 PM, John D. Ament <jo...@apache.org>
> wrote:
>
>> James,
>>
>> This is awesome, thank you!
>> Assuming we get through this first release, I want to share this document
>> with a broader audience to try to put together documented best practices
>> for the incubator release structure. This covers the maven side that I've
>> always seen as a problem.
>>
>> A couple of notes:
>>
>> - You may want to set push to false when doing a release. There's still a
>> lot of discussion out there, but it may be easier to manage a release off
>> of a fork rather than the main repo (and push to the main repo once the
>> release is done). There's trade offs either way.
>> - By not pushing, you eliminate the need to do an RC build as well.
>> - It would be great if release notes could come out of JIRA rather than
>> being checked in.
>> - The vote/discuss emails confuse me. Where did that come from? The most
>> I ever see (or expect to see) is a heads up style email saying someone is
>> thinking about cutting a release.
>>
>> Also, You don't need "Subject:" in your email subjects. I think we're also
>> missing the DISCLAIMER as well, indicating that this is a project under
>> incubation.
>>
>> John
>>
>> On Fri, Sep 30, 2016 at 12:29 PM James Bognar <james.bognar@salesforce.com
>> >
>> wrote:
>>
>> > New release guidelines are finished:
>> >
>> > <goog_1805653564>
>> > https://cwiki.apache.org/confluence/display/JUNEAU/New+
>> release+guidelines
>> >
>> > I'm ready to start a vote for juneau-6.0.0-incubating-RC1.
>> >
>> > --
>> > James Bognar
>> >
>>
>
>
>
> --
> James Bognar
--
Stian Soiland-Reyes
http://orcid.org/0000-0001-9842-9718
Re: Juneau new release guidelines.
Posted by Stian Soiland-Reyes <st...@apache.org>.
I've updated the release note docs (which is very nice!) to link to
the newer mail archive
https://lists.apache.org/list.html?dev@juneau.apache.org
It has much nicer threading, so I don't think we need to include the
permalinks for each binding vote (that's probably me being a bit too
rigid on the Taverna doc, we stopped doing that)
.. but including the [RESULT][VOTE] permalink when forwarding to
general@incubator is important - specially to move forward the
IPMC-binding votes.
On 1 October 2016 at 19:08, Stian Soiland-Reyes <st...@apache.org> wrote:
> You use X_VERSION=juneau-6.0.0-incubating-RC1 but later you use tag
> names "6.0.0-incubating-RC1" and refer to these as $X_VERSION -- which
> style of tags to go for?
>
> On 1 October 2016 at 16:09, James Bognar <ja...@salesforce.com> wrote:
>> Hi John,
>>
>> Much of the credit goes to Stian who pointed me to the Taverna instructions
>> from where I pulled much of the information:
>> https://taverna.incubator.apache.org/community
>>
>> I spent a lot of time just trying to get the formatting right in
>> Confluence. It's got a nice interface, but it's really buggy around
>> formatting. Sometimes I would do something to cause the formatting on half
>> the page to get messed up, and undo wouldn't fix it. Even now it looks
>> fine on Chrome/Firefox/Safari, but the fonts are messed up on
>> Safari-mobile. So be careful about that if you make any updates to the
>> page.
>>
>>>- You may want to set push to false when doing a release. There's still a lot
>> of discussion out there, but it may be easier to manage a release off
>>>of a fork rather than the main repo (and push to the main repo once the release
>> is done). There's trade offs either way.
>>>- By not pushing, you eliminate the need to do an RC build as well.
>>
>> Using a fork sounds good to me. I'm still not too familiar with Git. Can
>> you point me to an example of the instructions for doing so? (or simply
>> update the doc?) I've never tried creating or merging forks (even though I
>> know that's what Git is supposedly best at).
>>
>>>- It would be great if release notes could come out of JIRA rather than
>>>being checked in.
>>
>> Agreed. Do you know how to do that from a command line (create JIRA
>> versions, generate release notes, etc...)? If not, I can figure it out.
>>
>>> - The vote/discuss emails confuse me. Where did that come from? The most
>>> I ever see (or expect to see) is a heads up style email saying someone is
>>> thinking about cutting a release.
>>
>> That was based on the instructions from Taverna. Feel free to modify the
>> templates.
>>
>>> I think we're also missing the DISCLAIMER as well, indicating that this
>> is a project under incubation.
>> In the email to general@incubator?
>>
>> Thanks John!
>>
>>
>>
>>
>> On Fri, Sep 30, 2016 at 9:58 PM, John D. Ament <jo...@apache.org>
>> wrote:
>>
>>> James,
>>>
>>> This is awesome, thank you!
>>> Assuming we get through this first release, I want to share this document
>>> with a broader audience to try to put together documented best practices
>>> for the incubator release structure. This covers the maven side that I've
>>> always seen as a problem.
>>>
>>> A couple of notes:
>>>
>>> - You may want to set push to false when doing a release. There's still a
>>> lot of discussion out there, but it may be easier to manage a release off
>>> of a fork rather than the main repo (and push to the main repo once the
>>> release is done). There's trade offs either way.
>>> - By not pushing, you eliminate the need to do an RC build as well.
>>> - It would be great if release notes could come out of JIRA rather than
>>> being checked in.
>>> - The vote/discuss emails confuse me. Where did that come from? The most
>>> I ever see (or expect to see) is a heads up style email saying someone is
>>> thinking about cutting a release.
>>>
>>> Also, You don't need "Subject:" in your email subjects. I think we're also
>>> missing the DISCLAIMER as well, indicating that this is a project under
>>> incubation.
>>>
>>> John
>>>
>>> On Fri, Sep 30, 2016 at 12:29 PM James Bognar <james.bognar@salesforce.com
>>> >
>>> wrote:
>>>
>>> > New release guidelines are finished:
>>> >
>>> > <goog_1805653564>
>>> > https://cwiki.apache.org/confluence/display/JUNEAU/New+
>>> release+guidelines
>>> >
>>> > I'm ready to start a vote for juneau-6.0.0-incubating-RC1.
>>> >
>>> > --
>>> > James Bognar
>>> >
>>>
>>
>>
>>
>> --
>> James Bognar
>
>
>
> --
> Stian Soiland-Reyes
> http://orcid.org/0000-0001-9842-9718
--
Stian Soiland-Reyes
http://orcid.org/0000-0001-9842-9718
Re: Juneau new release guidelines.
Posted by Stian Soiland-Reyes <st...@apache.org>.
You use X_VERSION=juneau-6.0.0-incubating-RC1 but later you use tag
names "6.0.0-incubating-RC1" and refer to these as $X_VERSION -- which
style of tags to go for?
On 1 October 2016 at 16:09, James Bognar <ja...@salesforce.com> wrote:
> Hi John,
>
> Much of the credit goes to Stian who pointed me to the Taverna instructions
> from where I pulled much of the information:
> https://taverna.incubator.apache.org/community
>
> I spent a lot of time just trying to get the formatting right in
> Confluence. It's got a nice interface, but it's really buggy around
> formatting. Sometimes I would do something to cause the formatting on half
> the page to get messed up, and undo wouldn't fix it. Even now it looks
> fine on Chrome/Firefox/Safari, but the fonts are messed up on
> Safari-mobile. So be careful about that if you make any updates to the
> page.
>
>>- You may want to set push to false when doing a release. There's still a lot
> of discussion out there, but it may be easier to manage a release off
>>of a fork rather than the main repo (and push to the main repo once the release
> is done). There's trade offs either way.
>>- By not pushing, you eliminate the need to do an RC build as well.
>
> Using a fork sounds good to me. I'm still not too familiar with Git. Can
> you point me to an example of the instructions for doing so? (or simply
> update the doc?) I've never tried creating or merging forks (even though I
> know that's what Git is supposedly best at).
>
>>- It would be great if release notes could come out of JIRA rather than
>>being checked in.
>
> Agreed. Do you know how to do that from a command line (create JIRA
> versions, generate release notes, etc...)? If not, I can figure it out.
>
>> - The vote/discuss emails confuse me. Where did that come from? The most
>> I ever see (or expect to see) is a heads up style email saying someone is
>> thinking about cutting a release.
>
> That was based on the instructions from Taverna. Feel free to modify the
> templates.
>
>> I think we're also missing the DISCLAIMER as well, indicating that this
> is a project under incubation.
> In the email to general@incubator?
>
> Thanks John!
>
>
>
>
> On Fri, Sep 30, 2016 at 9:58 PM, John D. Ament <jo...@apache.org>
> wrote:
>
>> James,
>>
>> This is awesome, thank you!
>> Assuming we get through this first release, I want to share this document
>> with a broader audience to try to put together documented best practices
>> for the incubator release structure. This covers the maven side that I've
>> always seen as a problem.
>>
>> A couple of notes:
>>
>> - You may want to set push to false when doing a release. There's still a
>> lot of discussion out there, but it may be easier to manage a release off
>> of a fork rather than the main repo (and push to the main repo once the
>> release is done). There's trade offs either way.
>> - By not pushing, you eliminate the need to do an RC build as well.
>> - It would be great if release notes could come out of JIRA rather than
>> being checked in.
>> - The vote/discuss emails confuse me. Where did that come from? The most
>> I ever see (or expect to see) is a heads up style email saying someone is
>> thinking about cutting a release.
>>
>> Also, You don't need "Subject:" in your email subjects. I think we're also
>> missing the DISCLAIMER as well, indicating that this is a project under
>> incubation.
>>
>> John
>>
>> On Fri, Sep 30, 2016 at 12:29 PM James Bognar <james.bognar@salesforce.com
>> >
>> wrote:
>>
>> > New release guidelines are finished:
>> >
>> > <goog_1805653564>
>> > https://cwiki.apache.org/confluence/display/JUNEAU/New+
>> release+guidelines
>> >
>> > I'm ready to start a vote for juneau-6.0.0-incubating-RC1.
>> >
>> > --
>> > James Bognar
>> >
>>
>
>
>
> --
> James Bognar
--
Stian Soiland-Reyes
http://orcid.org/0000-0001-9842-9718
Re: Juneau new release guidelines.
Posted by Stian Soiland-Reyes <st...@apache.org>.
Thanks, I think you have made a much better version; hope you don't mind me
merging back again!
Is it OK if I fix some small things in the wiki (e.g. forgot svn mv of
binaries) or should I note it on this list? (Not sure if I have wiki access)
On 1 Oct 2016 4:09 p.m., "James Bognar" <ja...@salesforce.com> wrote:
> Hi John,
>
> Much of the credit goes to Stian who pointed me to the Taverna instructions
> from where I pulled much of the information:
> https://taverna.incubator.apache.org/community
>
> I spent a lot of time just trying to get the formatting right in
> Confluence. It's got a nice interface, but it's really buggy around
> formatting. Sometimes I would do something to cause the formatting on half
> the page to get messed up, and undo wouldn't fix it. Even now it looks
> fine on Chrome/Firefox/Safari, but the fonts are messed up on
> Safari-mobile. So be careful about that if you make any updates to the
> page.
>
> >- You may want to set push to false when doing a release. There's still
> a lot
> of discussion out there, but it may be easier to manage a release off
> >of a fork rather than the main repo (and push to the main repo once the
> release
> is done). There's trade offs either way.
> >- By not pushing, you eliminate the need to do an RC build as well.
>
> Using a fork sounds good to me. I'm still not too familiar with Git. Can
> you point me to an example of the instructions for doing so? (or simply
> update the doc?) I've never tried creating or merging forks (even though I
> know that's what Git is supposedly best at).
>
> >- It would be great if release notes could come out of JIRA rather than
> >being checked in.
>
> Agreed. Do you know how to do that from a command line (create JIRA
> versions, generate release notes, etc...)? If not, I can figure it out.
>
> > - The vote/discuss emails confuse me. Where did that come from? The
> most
> > I ever see (or expect to see) is a heads up style email saying someone is
> > thinking about cutting a release.
>
> That was based on the instructions from Taverna. Feel free to modify the
> templates.
>
> > I think we're also missing the DISCLAIMER as well, indicating that this
> is a project under incubation.
> In the email to general@incubator?
>
> Thanks John!
>
>
>
>
> On Fri, Sep 30, 2016 at 9:58 PM, John D. Ament <jo...@apache.org>
> wrote:
>
> > James,
> >
> > This is awesome, thank you!
> > Assuming we get through this first release, I want to share this document
> > with a broader audience to try to put together documented best practices
> > for the incubator release structure. This covers the maven side that
> I've
> > always seen as a problem.
> >
> > A couple of notes:
> >
> > - You may want to set push to false when doing a release. There's still
> a
> > lot of discussion out there, but it may be easier to manage a release off
> > of a fork rather than the main repo (and push to the main repo once the
> > release is done). There's trade offs either way.
> > - By not pushing, you eliminate the need to do an RC build as well.
> > - It would be great if release notes could come out of JIRA rather than
> > being checked in.
> > - The vote/discuss emails confuse me. Where did that come from? The
> most
> > I ever see (or expect to see) is a heads up style email saying someone is
> > thinking about cutting a release.
> >
> > Also, You don't need "Subject:" in your email subjects. I think we're
> also
> > missing the DISCLAIMER as well, indicating that this is a project under
> > incubation.
> >
> > John
> >
> > On Fri, Sep 30, 2016 at 12:29 PM James Bognar <
> james.bognar@salesforce.com
> > >
> > wrote:
> >
> > > New release guidelines are finished:
> > >
> > > <goog_1805653564>
> > > https://cwiki.apache.org/confluence/display/JUNEAU/New+
> > release+guidelines
> > >
> > > I'm ready to start a vote for juneau-6.0.0-incubating-RC1.
> > >
> > > --
> > > James Bognar
> > >
> >
>
>
>
> --
> James Bognar
>
Re: Juneau new release guidelines.
Posted by James Bognar <ja...@salesforce.com>.
> Maybe a better way to put it is maybe the list should be in chronological
> order.
Did some reordering, added JIRA instructions, got rid of the project-level
RELEASE-NOTES, renamed $X_VERSION to $X_RELEASE for clarity, and added
DISCLAIMER.
> Does your binary also shade in your 3rd party deps?
The juneau-samples.jar file is an executable uber jar that includes all 3rd
party dependencies. That's the only place we include them.
Still working on Git forking instructions.
On Sun, Oct 2, 2016 at 9:15 AM, John D. Ament <jo...@apache.org> wrote:
> On Sat, Oct 1, 2016 at 11:09 AM James Bognar <ja...@salesforce.com>
> wrote:
>
> > Hi John,
> >
> > Much of the credit goes to Stian who pointed me to the Taverna
> instructions
> > from where I pulled much of the information:
> > https://taverna.incubator.apache.org/community
> >
> > I spent a lot of time just trying to get the formatting right in
> > Confluence. It's got a nice interface, but it's really buggy around
> > formatting. Sometimes I would do something to cause the formatting on
> half
> > the page to get messed up, and undo wouldn't fix it. Even now it looks
> > fine on Chrome/Firefox/Safari, but the fonts are messed up on
> > Safari-mobile. So be careful about that if you make any updates to the
> > page.
> >
> > >- You may want to set push to false when doing a release. There's still
> > a lot
> > of discussion out there, but it may be easier to manage a release off
> > >of a fork rather than the main repo (and push to the main repo once the
> > release
> > is done). There's trade offs either way.
> > >- By not pushing, you eliminate the need to do an RC build as well.
> >
> > Using a fork sounds good to me. I'm still not too familiar with Git.
> Can
> > you point me to an example of the instructions for doing so? (or simply
> > update the doc?) I've never tried creating or merging forks (even
> though I
> > know that's what Git is supposedly best at).
> >
>
> Assuming you have a github account, if you go to
> https://github.com/apache/incubator-juneau you'll see a "Fork" button in
> the top right corner (it has a # next to it w/ the number of forks)
>
>
> >
> > >- It would be great if release notes could come out of JIRA rather than
> > >being checked in.
> >
> > Agreed. Do you know how to do that from a command line (create JIRA
> > versions, generate release notes, etc...)? If not, I can figure it out.
> >
>
> I don't. And for something like this, CLI isn't always the right
> solution. I usually go to pages like
> https://issues.apache.org/jira/browse/JUNEAU/fixforversion/12338351/?
> selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel
> and
> then click on "Release Notes" in the top right corner.
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12320520&version=12338351
>
> If you go there, you'll see a small issue w/ the release.
>
>
> >
> > > - The vote/discuss emails confuse me. Where did that come from? The
> > most
> > > I ever see (or expect to see) is a heads up style email saying someone
> is
> > > thinking about cutting a release.
> >
> > That was based on the instructions from Taverna. Feel free to modify the
> > templates.
> >
>
> Maybe a better way to put it is maybe the list should be in chronological
> order. You should discuss first, giving everyone notice, vote on the
> release in PPMC and then vote on IPMC.
>
> Now I want to throw this out there. I'm trying to help podlings stream
> line their process a little. Technically speaking, the PPMC vote is
> *optional*, the IPMC vote is required. The IPMC wants to see good faith
> that they're looking at a good release, but it doesn't mean the PPMC has to
> vote on it (the PPMC's votes are non binding, Craig, Jochen and I have
> binding votes). You could prep the release, let people know its out there
> to try out, and if we all say it looks good, move on to a IPMC vote.
>
> Since the code had an SGA sent for it, and there's no 3rd party code
> embedded, and you have minimal dependencies, as long as we get that
> disclaimer file in there for both source and binary, we're good.
>
> Does your binary also shade in your 3rd party deps?
>
>
> >
> > > I think we're also missing the DISCLAIMER as well, indicating that this
> > is a project under incubation.
> > In the email to general@incubator?
> >
> >
> No, you'll want to check in a copy of this file
> https://github.com/apache/incubator-tamaya/blob/master/DISCLAIMER and make
> sure it gets included in the release archives.
>
>
> > Thanks John!
> >
> >
> >
> >
> > On Fri, Sep 30, 2016 at 9:58 PM, John D. Ament <jo...@apache.org>
> > wrote:
> >
> > > James,
> > >
> > > This is awesome, thank you!
> > > Assuming we get through this first release, I want to share this
> document
> > > with a broader audience to try to put together documented best
> practices
> > > for the incubator release structure. This covers the maven side that
> > I've
> > > always seen as a problem.
> > >
> > > A couple of notes:
> > >
> > > - You may want to set push to false when doing a release. There's
> still
> > a
> > > lot of discussion out there, but it may be easier to manage a release
> off
> > > of a fork rather than the main repo (and push to the main repo once the
> > > release is done). There's trade offs either way.
> > > - By not pushing, you eliminate the need to do an RC build as well.
> > > - It would be great if release notes could come out of JIRA rather than
> > > being checked in.
> > > - The vote/discuss emails confuse me. Where did that come from? The
> > most
> > > I ever see (or expect to see) is a heads up style email saying someone
> is
> > > thinking about cutting a release.
> > >
> > > Also, You don't need "Subject:" in your email subjects. I think we're
> > also
> > > missing the DISCLAIMER as well, indicating that this is a project under
> > > incubation.
> > >
> > > John
> > >
> > > On Fri, Sep 30, 2016 at 12:29 PM James Bognar <
> > james.bognar@salesforce.com
> > > >
> > > wrote:
> > >
> > > > New release guidelines are finished:
> > > >
> > > > <goog_1805653564>
> > > > https://cwiki.apache.org/confluence/display/JUNEAU/New+
> > > release+guidelines
> > > >
> > > > I'm ready to start a vote for juneau-6.0.0-incubating-RC1.
> > > >
> > > > --
> > > > James Bognar
> > > >
> > >
> >
> >
> >
> > --
> > James Bognar
> >
>
--
James Bognar
Re: Juneau new release guidelines.
Posted by Stian Soiland-Reyes <st...@apache.org>.
I don't agree with the lightweight approach of PPMC, although technically a
podlong vote is not required, the podling should operate like a Top Level
Project in training from the start (with some rough bumps :-).
That said, I think in the beginning it's best for the PPMC release votes to
focus on the technical side, while IPMC votes (including binding votes from
mentors) should catch any license/IP discrepancies. The first incubator
releases don't have to be picture perfect, that's why we have the
DISCLAIMER file ☺
Later on both of these roles would be fulfilled by the PPMC (aspiring PMC)
vote. But to get there we have to start with following the release process
in principle.
On 2 Oct 2016 2:15 p.m., "John D. Ament" <jo...@apache.org> wrote:
On Sat, Oct 1, 2016 at 11:09 AM James Bognar <ja...@salesforce.com>
wrote:
> Hi John,
>
> Much of the credit goes to Stian who pointed me to the Taverna
instructions
> from where I pulled much of the information:
> https://taverna.incubator.apache.org/community
>
> I spent a lot of time just trying to get the formatting right in
> Confluence. It's got a nice interface, but it's really buggy around
> formatting. Sometimes I would do something to cause the formatting on
half
> the page to get messed up, and undo wouldn't fix it. Even now it looks
> fine on Chrome/Firefox/Safari, but the fonts are messed up on
> Safari-mobile. So be careful about that if you make any updates to the
> page.
>
> >- You may want to set push to false when doing a release. There's still
> a lot
> of discussion out there, but it may be easier to manage a release off
> >of a fork rather than the main repo (and push to the main repo once the
> release
> is done). There's trade offs either way.
> >- By not pushing, you eliminate the need to do an RC build as well.
>
> Using a fork sounds good to me. I'm still not too familiar with Git. Can
> you point me to an example of the instructions for doing so? (or simply
> update the doc?) I've never tried creating or merging forks (even though
I
> know that's what Git is supposedly best at).
>
Assuming you have a github account, if you go to
https://github.com/apache/incubator-juneau you'll see a "Fork" button in
the top right corner (it has a # next to it w/ the number of forks)
>
> >- It would be great if release notes could come out of JIRA rather than
> >being checked in.
>
> Agreed. Do you know how to do that from a command line (create JIRA
> versions, generate release notes, etc...)? If not, I can figure it out.
>
I don't. And for something like this, CLI isn't always the right
solution. I usually go to pages like
https://issues.apache.org/jira/browse/JUNEAU/fixforversion/12338351/?
selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel
and
then click on "Release Notes" in the top right corner.
https://issues.apache.org/jira/secure/ReleaseNote.jspa?
projectId=12320520&version=12338351
If you go there, you'll see a small issue w/ the release.
>
> > - The vote/discuss emails confuse me. Where did that come from? The
> most
> > I ever see (or expect to see) is a heads up style email saying someone
is
> > thinking about cutting a release.
>
> That was based on the instructions from Taverna. Feel free to modify the
> templates.
>
Maybe a better way to put it is maybe the list should be in chronological
order. You should discuss first, giving everyone notice, vote on the
release in PPMC and then vote on IPMC.
Now I want to throw this out there. I'm trying to help podlings stream
line their process a little. Technically speaking, the PPMC vote is
*optional*, the IPMC vote is required. The IPMC wants to see good faith
that they're looking at a good release, but it doesn't mean the PPMC has to
vote on it (the PPMC's votes are non binding, Craig, Jochen and I have
binding votes). You could prep the release, let people know its out there
to try out, and if we all say it looks good, move on to a IPMC vote.
Since the code had an SGA sent for it, and there's no 3rd party code
embedded, and you have minimal dependencies, as long as we get that
disclaimer file in there for both source and binary, we're good.
Does your binary also shade in your 3rd party deps?
>
> > I think we're also missing the DISCLAIMER as well, indicating that this
> is a project under incubation.
> In the email to general@incubator?
>
>
No, you'll want to check in a copy of this file
https://github.com/apache/incubator-tamaya/blob/master/DISCLAIMER and make
sure it gets included in the release archives.
> Thanks John!
>
>
>
>
> On Fri, Sep 30, 2016 at 9:58 PM, John D. Ament <jo...@apache.org>
> wrote:
>
> > James,
> >
> > This is awesome, thank you!
> > Assuming we get through this first release, I want to share this
document
> > with a broader audience to try to put together documented best practices
> > for the incubator release structure. This covers the maven side that
> I've
> > always seen as a problem.
> >
> > A couple of notes:
> >
> > - You may want to set push to false when doing a release. There's still
> a
> > lot of discussion out there, but it may be easier to manage a release
off
> > of a fork rather than the main repo (and push to the main repo once the
> > release is done). There's trade offs either way.
> > - By not pushing, you eliminate the need to do an RC build as well.
> > - It would be great if release notes could come out of JIRA rather than
> > being checked in.
> > - The vote/discuss emails confuse me. Where did that come from? The
> most
> > I ever see (or expect to see) is a heads up style email saying someone
is
> > thinking about cutting a release.
> >
> > Also, You don't need "Subject:" in your email subjects. I think we're
> also
> > missing the DISCLAIMER as well, indicating that this is a project under
> > incubation.
> >
> > John
> >
> > On Fri, Sep 30, 2016 at 12:29 PM James Bognar <
> james.bognar@salesforce.com
> > >
> > wrote:
> >
> > > New release guidelines are finished:
> > >
> > > <goog_1805653564>
> > > https://cwiki.apache.org/confluence/display/JUNEAU/New+
> > release+guidelines
> > >
> > > I'm ready to start a vote for juneau-6.0.0-incubating-RC1.
> > >
> > > --
> > > James Bognar
> > >
> >
>
>
>
> --
> James Bognar
>
Re: Juneau new release guidelines.
Posted by "John D. Ament" <jo...@apache.org>.
On Sat, Oct 1, 2016 at 11:09 AM James Bognar <ja...@salesforce.com>
wrote:
> Hi John,
>
> Much of the credit goes to Stian who pointed me to the Taverna instructions
> from where I pulled much of the information:
> https://taverna.incubator.apache.org/community
>
> I spent a lot of time just trying to get the formatting right in
> Confluence. It's got a nice interface, but it's really buggy around
> formatting. Sometimes I would do something to cause the formatting on half
> the page to get messed up, and undo wouldn't fix it. Even now it looks
> fine on Chrome/Firefox/Safari, but the fonts are messed up on
> Safari-mobile. So be careful about that if you make any updates to the
> page.
>
> >- You may want to set push to false when doing a release. There's still
> a lot
> of discussion out there, but it may be easier to manage a release off
> >of a fork rather than the main repo (and push to the main repo once the
> release
> is done). There's trade offs either way.
> >- By not pushing, you eliminate the need to do an RC build as well.
>
> Using a fork sounds good to me. I'm still not too familiar with Git. Can
> you point me to an example of the instructions for doing so? (or simply
> update the doc?) I've never tried creating or merging forks (even though I
> know that's what Git is supposedly best at).
>
Assuming you have a github account, if you go to
https://github.com/apache/incubator-juneau you'll see a "Fork" button in
the top right corner (it has a # next to it w/ the number of forks)
>
> >- It would be great if release notes could come out of JIRA rather than
> >being checked in.
>
> Agreed. Do you know how to do that from a command line (create JIRA
> versions, generate release notes, etc...)? If not, I can figure it out.
>
I don't. And for something like this, CLI isn't always the right
solution. I usually go to pages like
https://issues.apache.org/jira/browse/JUNEAU/fixforversion/12338351/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel
and
then click on "Release Notes" in the top right corner.
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320520&version=12338351
If you go there, you'll see a small issue w/ the release.
>
> > - The vote/discuss emails confuse me. Where did that come from? The
> most
> > I ever see (or expect to see) is a heads up style email saying someone is
> > thinking about cutting a release.
>
> That was based on the instructions from Taverna. Feel free to modify the
> templates.
>
Maybe a better way to put it is maybe the list should be in chronological
order. You should discuss first, giving everyone notice, vote on the
release in PPMC and then vote on IPMC.
Now I want to throw this out there. I'm trying to help podlings stream
line their process a little. Technically speaking, the PPMC vote is
*optional*, the IPMC vote is required. The IPMC wants to see good faith
that they're looking at a good release, but it doesn't mean the PPMC has to
vote on it (the PPMC's votes are non binding, Craig, Jochen and I have
binding votes). You could prep the release, let people know its out there
to try out, and if we all say it looks good, move on to a IPMC vote.
Since the code had an SGA sent for it, and there's no 3rd party code
embedded, and you have minimal dependencies, as long as we get that
disclaimer file in there for both source and binary, we're good.
Does your binary also shade in your 3rd party deps?
>
> > I think we're also missing the DISCLAIMER as well, indicating that this
> is a project under incubation.
> In the email to general@incubator?
>
>
No, you'll want to check in a copy of this file
https://github.com/apache/incubator-tamaya/blob/master/DISCLAIMER and make
sure it gets included in the release archives.
> Thanks John!
>
>
>
>
> On Fri, Sep 30, 2016 at 9:58 PM, John D. Ament <jo...@apache.org>
> wrote:
>
> > James,
> >
> > This is awesome, thank you!
> > Assuming we get through this first release, I want to share this document
> > with a broader audience to try to put together documented best practices
> > for the incubator release structure. This covers the maven side that
> I've
> > always seen as a problem.
> >
> > A couple of notes:
> >
> > - You may want to set push to false when doing a release. There's still
> a
> > lot of discussion out there, but it may be easier to manage a release off
> > of a fork rather than the main repo (and push to the main repo once the
> > release is done). There's trade offs either way.
> > - By not pushing, you eliminate the need to do an RC build as well.
> > - It would be great if release notes could come out of JIRA rather than
> > being checked in.
> > - The vote/discuss emails confuse me. Where did that come from? The
> most
> > I ever see (or expect to see) is a heads up style email saying someone is
> > thinking about cutting a release.
> >
> > Also, You don't need "Subject:" in your email subjects. I think we're
> also
> > missing the DISCLAIMER as well, indicating that this is a project under
> > incubation.
> >
> > John
> >
> > On Fri, Sep 30, 2016 at 12:29 PM James Bognar <
> james.bognar@salesforce.com
> > >
> > wrote:
> >
> > > New release guidelines are finished:
> > >
> > > <goog_1805653564>
> > > https://cwiki.apache.org/confluence/display/JUNEAU/New+
> > release+guidelines
> > >
> > > I'm ready to start a vote for juneau-6.0.0-incubating-RC1.
> > >
> > > --
> > > James Bognar
> > >
> >
>
>
>
> --
> James Bognar
>
Re: Juneau new release guidelines.
Posted by James Bognar <ja...@salesforce.com>.
Hi John,
Much of the credit goes to Stian who pointed me to the Taverna instructions
from where I pulled much of the information:
https://taverna.incubator.apache.org/community
I spent a lot of time just trying to get the formatting right in
Confluence. It's got a nice interface, but it's really buggy around
formatting. Sometimes I would do something to cause the formatting on half
the page to get messed up, and undo wouldn't fix it. Even now it looks
fine on Chrome/Firefox/Safari, but the fonts are messed up on
Safari-mobile. So be careful about that if you make any updates to the
page.
>- You may want to set push to false when doing a release. There's still a lot
of discussion out there, but it may be easier to manage a release off
>of a fork rather than the main repo (and push to the main repo once the release
is done). There's trade offs either way.
>- By not pushing, you eliminate the need to do an RC build as well.
Using a fork sounds good to me. I'm still not too familiar with Git. Can
you point me to an example of the instructions for doing so? (or simply
update the doc?) I've never tried creating or merging forks (even though I
know that's what Git is supposedly best at).
>- It would be great if release notes could come out of JIRA rather than
>being checked in.
Agreed. Do you know how to do that from a command line (create JIRA
versions, generate release notes, etc...)? If not, I can figure it out.
> - The vote/discuss emails confuse me. Where did that come from? The most
> I ever see (or expect to see) is a heads up style email saying someone is
> thinking about cutting a release.
That was based on the instructions from Taverna. Feel free to modify the
templates.
> I think we're also missing the DISCLAIMER as well, indicating that this
is a project under incubation.
In the email to general@incubator?
Thanks John!
On Fri, Sep 30, 2016 at 9:58 PM, John D. Ament <jo...@apache.org>
wrote:
> James,
>
> This is awesome, thank you!
> Assuming we get through this first release, I want to share this document
> with a broader audience to try to put together documented best practices
> for the incubator release structure. This covers the maven side that I've
> always seen as a problem.
>
> A couple of notes:
>
> - You may want to set push to false when doing a release. There's still a
> lot of discussion out there, but it may be easier to manage a release off
> of a fork rather than the main repo (and push to the main repo once the
> release is done). There's trade offs either way.
> - By not pushing, you eliminate the need to do an RC build as well.
> - It would be great if release notes could come out of JIRA rather than
> being checked in.
> - The vote/discuss emails confuse me. Where did that come from? The most
> I ever see (or expect to see) is a heads up style email saying someone is
> thinking about cutting a release.
>
> Also, You don't need "Subject:" in your email subjects. I think we're also
> missing the DISCLAIMER as well, indicating that this is a project under
> incubation.
>
> John
>
> On Fri, Sep 30, 2016 at 12:29 PM James Bognar <james.bognar@salesforce.com
> >
> wrote:
>
> > New release guidelines are finished:
> >
> > <goog_1805653564>
> > https://cwiki.apache.org/confluence/display/JUNEAU/New+
> release+guidelines
> >
> > I'm ready to start a vote for juneau-6.0.0-incubating-RC1.
> >
> > --
> > James Bognar
> >
>
--
James Bognar
Re: Juneau new release guidelines.
Posted by "John D. Ament" <jo...@apache.org>.
James,
This is awesome, thank you!
Assuming we get through this first release, I want to share this document
with a broader audience to try to put together documented best practices
for the incubator release structure. This covers the maven side that I've
always seen as a problem.
A couple of notes:
- You may want to set push to false when doing a release. There's still a
lot of discussion out there, but it may be easier to manage a release off
of a fork rather than the main repo (and push to the main repo once the
release is done). There's trade offs either way.
- By not pushing, you eliminate the need to do an RC build as well.
- It would be great if release notes could come out of JIRA rather than
being checked in.
- The vote/discuss emails confuse me. Where did that come from? The most
I ever see (or expect to see) is a heads up style email saying someone is
thinking about cutting a release.
Also, You don't need "Subject:" in your email subjects. I think we're also
missing the DISCLAIMER as well, indicating that this is a project under
incubation.
John
On Fri, Sep 30, 2016 at 12:29 PM James Bognar <ja...@salesforce.com>
wrote:
> New release guidelines are finished:
>
> <goog_1805653564>
> https://cwiki.apache.org/confluence/display/JUNEAU/New+release+guidelines
>
> I'm ready to start a vote for juneau-6.0.0-incubating-RC1.
>
> --
> James Bognar
>