Re: [jira] Closed: (SHIRO-102) Set-up AutoExport of Shiro documentation to the appropriate location

[Les Hazlewood <lh...@apache.org>]

Excellent!

Now the question is - we're all done with 1.0 issues.  How do we start
the release process?

If possible, I'd like to clean up JavaDoc over the next 2 to 3 hours,
but I think we should definitely start the release process after that.
 Is that OK?


> Kalle Korhonen closed SHIRO-102.
> --------------------------------
>
>    Resolution: Fixed

Re: [jira] Closed: (SHIRO-102) Set-up AutoExport of Shiro documentation to the appropriate location

[Paul Merlin <es...@n0pe.org>]

Le jeudi 20 mai 2010 07:40:51, Kalle Korhonen a écrit :
> On Wed, May 19, 2010 at 11:19 AM, Les Hazlewood <lh...@apache.org> wrote:
> >> But if you feel strongly about it, I can create the branch right away.
> > 
> > Nope - no strong opinions.  I can wait.  I was just looking at the
> > 1.0.1 Jira issues, and 2 of them actually look like non-backwards
> > compatible changes and would have to be moved to 1.1.  I was thinking
> > that if anyone wanted to do that stuff anytime soon, they'd probably
> > need to have a 1.0.x branch made so they can do the 1.1 development in
> > the trunk. But I don't think I'm going to attack these immediately, so
> > I can certainly wait :)
> 
> Well, in that case. Of course the coin side of it is that if we get
> the 1.1 out before any critical issues arise we don't necessarily ever
> have to come up with 1.0.1. I'll create the branch before I start the
> release process tomorrow morning. I just ran the release dryRun and
> although there's a few fixes I still need to make, I have some faith
> in the current pom configuration and hopefully won't need to make too
> many final adjustments to the poms.

Just a thought. You can create the branch from the 1.0.0 tag or from the trunk 
revision of the 1.0.0 release when needed, you're not forced to branch from the 
trunk/HEAD right away.

/Paul

Re: [jira] Closed: (SHIRO-102) Set-up AutoExport of Shiro documentation to the appropriate location

[Les Hazlewood <lh...@apache.org>]

Yeah, there's a 'must' in there as well (last sentence in the 3rd
paragraph under 'Naming'):

"Incubator policy insists that it must also contain incubating (though
small variations for the sake of readability are usually acceptable)."
 Where 'incubating' is in monospaced font. :/

On Wed, May 19, 2010 at 11:02 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Missed that, thanks for digging it out. "should" is perhaps a little
> vague, but I guess it makes most sense to keep it as part of version
> coordinate. We'll go with that.
>
> Kalle
>
>
> On Wed, May 19, 2010 at 10:53 PM, Les Hazlewood <lh...@apache.org> wrote:
>> Oops.  This states it is a required policy to have the '-incubating'
>> in the name:
>>
>> http://incubator.apache.org/guides/releasemanagement.html#naming
>>
>> On Wed, May 19, 2010 at 10:51 PM, Les Hazlewood <lh...@apache.org> wrote:
>>> I don't know if it is a hard requirement.  I don't *think* so, but I
>>> could be wrong.
>>>
>>> You could always create the artifacts without the suffix and see if
>>> the Mentors and then Incubator PMC approves them.  Coupled with clear
>>> notes about the incubating status, it may fly.
>>>
>>> +1 to not having it in the actual artifact name but make it clear as
>>> day on the website and in the release notes.
>>>
>>> On Wed, May 19, 2010 at 10:40 PM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>>> On Wed, May 19, 2010 at 11:19 AM, Les Hazlewood <lh...@apache.org> wrote:
>>>>>> But if you feel strongly about it, I can create the branch right away.
>>>>> Nope - no strong opinions.  I can wait.  I was just looking at the
>>>>> 1.0.1 Jira issues, and 2 of them actually look like non-backwards
>>>>> compatible changes and would have to be moved to 1.1.  I was thinking
>>>>> that if anyone wanted to do that stuff anytime soon, they'd probably
>>>>> need to have a 1.0.x branch made so they can do the 1.1 development in
>>>>> the trunk. But I don't think I'm going to attack these immediately, so
>>>>> I can certainly wait :)
>>>>
>>>> Well, in that case. Of course the coin side of it is that if we get
>>>> the 1.1 out before any critical issues arise we don't necessarily ever
>>>> have to come up with 1.0.1. I'll create the branch before I start the
>>>> release process tomorrow morning. I just ran the release dryRun and
>>>> although there's a few fixes I still need to make, I have some faith
>>>> in the current pom configuration and hopefully won't need to make too
>>>> many final adjustments to the poms.
>>>>
>>>> One more: the current version carries the -incubating label in the
>>>> version - do you know if it's a requirement or can we simply release
>>>> 1.0.0? It was my understanding from the discussions that it's the same
>>>> as with RCs - they are not needed as part of the version but the
>>>> incubation status can simply be acknowledged in the release notes. And
>>>> actually, I do remember that at least CXF used plain version digits
>>>> while they were still in incubator.
>>>>
>>>> Kalle
>>>>
>>>
>>
>

Re: [jira] Closed: (SHIRO-102) Set-up AutoExport of Shiro documentation to the appropriate location

[Kalle Korhonen <ka...@gmail.com>]

Missed that, thanks for digging it out. "should" is perhaps a little
vague, but I guess it makes most sense to keep it as part of version
coordinate. We'll go with that.

Kalle


On Wed, May 19, 2010 at 10:53 PM, Les Hazlewood <lh...@apache.org> wrote:
> Oops.  This states it is a required policy to have the '-incubating'
> in the name:
>
> http://incubator.apache.org/guides/releasemanagement.html#naming
>
> On Wed, May 19, 2010 at 10:51 PM, Les Hazlewood <lh...@apache.org> wrote:
>> I don't know if it is a hard requirement.  I don't *think* so, but I
>> could be wrong.
>>
>> You could always create the artifacts without the suffix and see if
>> the Mentors and then Incubator PMC approves them.  Coupled with clear
>> notes about the incubating status, it may fly.
>>
>> +1 to not having it in the actual artifact name but make it clear as
>> day on the website and in the release notes.
>>
>> On Wed, May 19, 2010 at 10:40 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>> On Wed, May 19, 2010 at 11:19 AM, Les Hazlewood <lh...@apache.org> wrote:
>>>>> But if you feel strongly about it, I can create the branch right away.
>>>> Nope - no strong opinions.  I can wait.  I was just looking at the
>>>> 1.0.1 Jira issues, and 2 of them actually look like non-backwards
>>>> compatible changes and would have to be moved to 1.1.  I was thinking
>>>> that if anyone wanted to do that stuff anytime soon, they'd probably
>>>> need to have a 1.0.x branch made so they can do the 1.1 development in
>>>> the trunk. But I don't think I'm going to attack these immediately, so
>>>> I can certainly wait :)
>>>
>>> Well, in that case. Of course the coin side of it is that if we get
>>> the 1.1 out before any critical issues arise we don't necessarily ever
>>> have to come up with 1.0.1. I'll create the branch before I start the
>>> release process tomorrow morning. I just ran the release dryRun and
>>> although there's a few fixes I still need to make, I have some faith
>>> in the current pom configuration and hopefully won't need to make too
>>> many final adjustments to the poms.
>>>
>>> One more: the current version carries the -incubating label in the
>>> version - do you know if it's a requirement or can we simply release
>>> 1.0.0? It was my understanding from the discussions that it's the same
>>> as with RCs - they are not needed as part of the version but the
>>> incubation status can simply be acknowledged in the release notes. And
>>> actually, I do remember that at least CXF used plain version digits
>>> while they were still in incubator.
>>>
>>> Kalle
>>>
>>
>

Re: [jira] Closed: (SHIRO-102) Set-up AutoExport of Shiro documentation to the appropriate location

[Les Hazlewood <lh...@apache.org>]

Oops.  This states it is a required policy to have the '-incubating'
in the name:

http://incubator.apache.org/guides/releasemanagement.html#naming

On Wed, May 19, 2010 at 10:51 PM, Les Hazlewood <lh...@apache.org> wrote:
> I don't know if it is a hard requirement.  I don't *think* so, but I
> could be wrong.
>
> You could always create the artifacts without the suffix and see if
> the Mentors and then Incubator PMC approves them.  Coupled with clear
> notes about the incubating status, it may fly.
>
> +1 to not having it in the actual artifact name but make it clear as
> day on the website and in the release notes.
>
> On Wed, May 19, 2010 at 10:40 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> On Wed, May 19, 2010 at 11:19 AM, Les Hazlewood <lh...@apache.org> wrote:
>>>> But if you feel strongly about it, I can create the branch right away.
>>> Nope - no strong opinions.  I can wait.  I was just looking at the
>>> 1.0.1 Jira issues, and 2 of them actually look like non-backwards
>>> compatible changes and would have to be moved to 1.1.  I was thinking
>>> that if anyone wanted to do that stuff anytime soon, they'd probably
>>> need to have a 1.0.x branch made so they can do the 1.1 development in
>>> the trunk. But I don't think I'm going to attack these immediately, so
>>> I can certainly wait :)
>>
>> Well, in that case. Of course the coin side of it is that if we get
>> the 1.1 out before any critical issues arise we don't necessarily ever
>> have to come up with 1.0.1. I'll create the branch before I start the
>> release process tomorrow morning. I just ran the release dryRun and
>> although there's a few fixes I still need to make, I have some faith
>> in the current pom configuration and hopefully won't need to make too
>> many final adjustments to the poms.
>>
>> One more: the current version carries the -incubating label in the
>> version - do you know if it's a requirement or can we simply release
>> 1.0.0? It was my understanding from the discussions that it's the same
>> as with RCs - they are not needed as part of the version but the
>> incubation status can simply be acknowledged in the release notes. And
>> actually, I do remember that at least CXF used plain version digits
>> while they were still in incubator.
>>
>> Kalle
>>
>

Re: [jira] Closed: (SHIRO-102) Set-up AutoExport of Shiro documentation to the appropriate location

[Les Hazlewood <lh...@apache.org>]

I don't know if it is a hard requirement.  I don't *think* so, but I
could be wrong.

You could always create the artifacts without the suffix and see if
the Mentors and then Incubator PMC approves them.  Coupled with clear
notes about the incubating status, it may fly.

+1 to not having it in the actual artifact name but make it clear as
day on the website and in the release notes.

On Wed, May 19, 2010 at 10:40 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> On Wed, May 19, 2010 at 11:19 AM, Les Hazlewood <lh...@apache.org> wrote:
>>> But if you feel strongly about it, I can create the branch right away.
>> Nope - no strong opinions.  I can wait.  I was just looking at the
>> 1.0.1 Jira issues, and 2 of them actually look like non-backwards
>> compatible changes and would have to be moved to 1.1.  I was thinking
>> that if anyone wanted to do that stuff anytime soon, they'd probably
>> need to have a 1.0.x branch made so they can do the 1.1 development in
>> the trunk. But I don't think I'm going to attack these immediately, so
>> I can certainly wait :)
>
> Well, in that case. Of course the coin side of it is that if we get
> the 1.1 out before any critical issues arise we don't necessarily ever
> have to come up with 1.0.1. I'll create the branch before I start the
> release process tomorrow morning. I just ran the release dryRun and
> although there's a few fixes I still need to make, I have some faith
> in the current pom configuration and hopefully won't need to make too
> many final adjustments to the poms.
>
> One more: the current version carries the -incubating label in the
> version - do you know if it's a requirement or can we simply release
> 1.0.0? It was my understanding from the discussions that it's the same
> as with RCs - they are not needed as part of the version but the
> incubation status can simply be acknowledged in the release notes. And
> actually, I do remember that at least CXF used plain version digits
> while they were still in incubator.
>
> Kalle
>

Re: [jira] Closed: (SHIRO-102) Set-up AutoExport of Shiro documentation to the appropriate location

[Kalle Korhonen <ka...@gmail.com>]

On Wed, May 19, 2010 at 11:19 AM, Les Hazlewood <lh...@apache.org> wrote:
>> But if you feel strongly about it, I can create the branch right away.
> Nope - no strong opinions.  I can wait.  I was just looking at the
> 1.0.1 Jira issues, and 2 of them actually look like non-backwards
> compatible changes and would have to be moved to 1.1.  I was thinking
> that if anyone wanted to do that stuff anytime soon, they'd probably
> need to have a 1.0.x branch made so they can do the 1.1 development in
> the trunk. But I don't think I'm going to attack these immediately, so
> I can certainly wait :)

Well, in that case. Of course the coin side of it is that if we get
the 1.1 out before any critical issues arise we don't necessarily ever
have to come up with 1.0.1. I'll create the branch before I start the
release process tomorrow morning. I just ran the release dryRun and
although there's a few fixes I still need to make, I have some faith
in the current pom configuration and hopefully won't need to make too
many final adjustments to the poms.

One more: the current version carries the -incubating label in the
version - do you know if it's a requirement or can we simply release
1.0.0? It was my understanding from the discussions that it's the same
as with RCs - they are not needed as part of the version but the
incubation status can simply be acknowledged in the release notes. And
actually, I do remember that at least CXF used plain version digits
while they were still in incubator.

Kalle

Re: [jira] Closed: (SHIRO-102) Set-up AutoExport of Shiro documentation to the appropriate location

[Les Hazlewood <lh...@apache.org>]

> Yes, like I said, creating the branch itself is cheap. It's the
> additional overhead - two CI builds, periodic merges and co-ordination
> that, while not much, makes sense to defer till the time you actually
> need it. All I'm saying is that we can create the branch at any point
> later once somebody wants to work on an issue that's targeted for 1.1.
> But if you feel strongly about it, I can create the branch right away.

Nope - no strong opinions.  I can wait.  I was just looking at the
1.0.1 Jira issues, and 2 of them actually look like non-backwards
compatible changes and would have to be moved to 1.1.  I was thinking
that if anyone wanted to do that stuff anytime soon, they'd probably
need to have a 1.0.x branch made so they can do the 1.1 development in
the trunk. But I don't think I'm going to attack these immediately, so
I can certainly wait :)

Re: [jira] Closed: (SHIRO-102) Set-up AutoExport of Shiro documentation to the appropriate location

[Kalle Korhonen <ka...@gmail.com>]

On Wed, May 19, 2010 at 10:49 AM, Les Hazlewood <lh...@apache.org> wrote:
> Won't the release plugin automatically create the 1.0.x branch?  That
> way we don't have to worry about it?

You can create a branch using the release plugin with mvn release:branch.

> Unless I'm missing something, it makes sense to me to create a 1.0.x
> because the trunk can be used for new feature (1.1) development -
> there are a few issues slated for 1.1 already and we would be able to
> work on those whenever we want without fear of screwing up the repo if
> there is already a 1.0.x branch, right?  I mean, the idea is that
> 1.0.x won't contain new features since it should be both forwards and
> backwards compatible with any 1.0.x release.  At least this has been
> my favorite way of thinking of releases:

Yes, like I said, creating the branch itself is cheap. It's the
additional overhead - two CI builds, periodic merges and co-ordination
that, while not much, makes sense to defer till the time you actually
need it. All I'm saying is that we can create the branch at any point
later once somebody wants to work on an issue that's targeted for 1.1.
But if you feel strongly about it, I can create the branch right away.

Kalle

Re: [jira] Closed: (SHIRO-102) Set-up AutoExport of Shiro documentation to the appropriate location

[Les Hazlewood <lh...@apache.org>]

> Sure, clean up the javadoc. I'm still checking the configuration and
> the site and that I've done all the preparation needed for the
> release. I don't think I can start the release today though. It should
> be simple and quick if everything works out but from the past
> experience of cutting the very first release, you may need a
> continuous block of several hours to work through the remaining issues
> and I don't have that today. Overall, tomorrow morning works better
> for me.

Sure, no problem - that will give me a bit of time for JavaDoc'ing and
documentation.  Let me know if I can do anything to help along the
way.

> On branches: while they are cheap to create, I'd resist creating a
> release branch just for getting 1.0.0 out. In practice, we are the
> only two active committers at the moment so we can easily handle the
> communication. Also we really don't have any idea for a feature set
> for 1.1, so creating a 1.0.x release branch at this time is pointless.
> Once the release is done, development of 1.0.1 release will continue
> in the trunk until we identify an issue to work on that should be
> scheduled for some other release than 1.0.1.

Won't the release plugin automatically create the 1.0.x branch?  That
way we don't have to worry about it?

Unless I'm missing something, it makes sense to me to create a 1.0.x
because the trunk can be used for new feature (1.1) development -
there are a few issues slated for 1.1 already and we would be able to
work on those whenever we want without fear of screwing up the repo if
there is already a 1.0.x branch, right?  I mean, the idea is that
1.0.x won't contain new features since it should be both forwards and
backwards compatible with any 1.0.x release.  At least this has been
my favorite way of thinking of releases:

http://apr.apache.org/versioning.html

I'm also thinking of how we did things w/ Maven at work - this entire
thing was automated such that a tag and branch were created
automatically at every release and we never had to worry about it.

Thoughts?

Les

Re: [jira] Closed: (SHIRO-102) Set-up AutoExport of Shiro documentation to the appropriate location

[Kalle Korhonen <ka...@gmail.com>]

On Wed, May 19, 2010 at 9:52 AM, Les Hazlewood <lh...@apache.org> wrote:
> Excellent!
> Now the question is - we're all done with 1.0 issues.  How do we start
> the release process?
> If possible, I'd like to clean up JavaDoc over the next 2 to 3 hours,
> but I think we should definitely start the release process after that.
>  Is that OK?

Sure, clean up the javadoc. I'm still checking the configuration and
the site and that I've done all the preparation needed for the
release. I don't think I can start the release today though. It should
be simple and quick if everything works out but from the past
experience of cutting the very first release, you may need a
continuous block of several hours to work through the remaining issues
and I don't have that today. Overall, tomorrow morning works better
for me.

On branches: while they are cheap to create, I'd resist creating a
release branch just for getting 1.0.0 out. In practice, we are the
only two active committers at the moment so we can easily handle the
communication. Also we really don't have any idea for a feature set
for 1.1, so creating a 1.0.x release branch at this time is pointless.
Once the release is done, development of 1.0.1 release will continue
in the trunk until we identify an issue to work on that should be
scheduled for some other release than 1.0.1.

Kalle

Re: [jira] Closed: (SHIRO-102) Set-up AutoExport of Shiro documentation to the appropriate location

["Alan D. Cabrera" <li...@toolazydogs.com>]

Les,

It's incredibly bad form to start email threads from Jira notifications.  It's even worse form to start a new topic on Jira notifications.   Let's start a new thread please.


Regards,
Alan

On May 19, 2010, at 9:52 AM, Les Hazlewood wrote:

> Excellent!
> 
> Now the question is - we're all done with 1.0 issues.  How do we start
> the release process?
> 
> If possible, I'd like to clean up JavaDoc over the next 2 to 3 hours,
> but I think we should definitely start the release process after that.
> Is that OK?
> 
> 
>> Kalle Korhonen closed SHIRO-102.
>> --------------------------------
>> 
>>    Resolution: Fixed