You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@allura.apache.org by Dave Brondsema <da...@brondsema.net> on 2014/01/13 16:32:03 UTC
Re: when to do a next Allura release?
Blocking github-importer tickets https://sourceforge.net/p/allura/tickets/6922/
and https://sourceforge.net/p/allura/tickets/6993/ are now closed, so we could
do a release with all the importers enabled now.
However I said [1] that we'd also remove a SourceForge reference on a repo page
before our next release, so I think we should do some work on
https://sourceforge.net/p/allura/tickets/4808/
[1]
http://mail-archives.apache.org/mod_mbox/incubator-general/201311.mbox/%3C527D32D4.9000709%40brondsema.net%3E
On 12/10/13 3:28 PM, Cory Johns wrote:
> Agreed. Having all of our current importers enabled seems like a good spot
> to release, as does activity streams.
>
> I think we should try not to ever go more than 2 months without doing a
> release, and I might even say 1 release per month might be a good target
> though we can start with 2 and see how that goes.
>
>
> On Tue, Dec 10, 2013 at 2:36 PM, Dave Brondsema <da...@brondsema.net> wrote:
>
>> How frequently do we want to make Allura releases? Particularly when do
>> we want
>> to make our next one - but we can talk in general terms too.
>>
>> I am thinking we should do one fairly soon. It took a while to get our
>> first
>> release out, but we now have a release script which should help automate a
>> lot
>> and ensure we cover all the technical aspects. And I think we'll be able
>> to get
>> the votes more easily now that we've gotten past the hurdle of the first
>> one.
>> Also, the Incubator PMC (IPMC) has voted & invited me to join the IPMC a
>> little
>> while ago, so I can cast a binding vote too.
>>
>> In general, I'd suggest we make releases after certain significant
>> features are
>> done, or after a few months if we're doing many small/medium changes but
>> nothing
>> too big. Lately we've done a lot of work around Google, Trac, and Github
>> importers. IMO https://sourceforge.net/p/allura/tickets/6922/ is a
>> blocker for
>> github, but after that is fixed might be a good time to release. Another
>> big
>> ongoing initiative is activity streams, which might make a good 3rd
>> release).
>>
>> --
>> Dave Brondsema : dave@brondsema.net
>> http://www.brondsema.net : personal
>> http://www.splike.com : programming
>> <><
>>
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: when to do a next Allura release?
Posted by Dave Brondsema <da...@brondsema.net>.
On 1/24/14 4:24 PM, Cory Johns wrote:
> The release script will update, commit, and tag the CHANGELOG, and it will
> build the artifacts and put them in /tmp/allura-incubating-$VERSON. You'll
> need to push the CHANGELOG commit and tag, and move the artifacts to your
> ASF repo dir and commit them, and of course make the mailing list thread.
Thanks, I'm working through it now and will post a VOTE thread once I've got it
all together.
>
> I'm fine with 1.1.0. Third-party tools will only break if they don't use
> EasyWidgets for their forms, right?
Right.
>
>
> On Fri, Jan 24, 2014 at 4:11 PM, Dave Brondsema <da...@brondsema.net> wrote:
>
>> With 4808 closed now, I think we're primed for our next release. I'm
>> interested
>> in running this one. I assume I can just run the scripts/asf-release.sh
>> script
>> that Cory wrote, right?
>>
>> We talked a bit about versioning, anyone have a strong feeling for what
>> this one
>> will be? Maybe I need to look at the changelog but I'm inclined for 1.1.0
>> rather than 2.0.0 even though technically 3rd-party Allura tools may likely
>> break, due to CSRF changes. Doesn't seem like a "big enough" breaking
>> change to me.
>>
>> On 1/13/14 10:32 AM, Dave Brondsema wrote:
>>> Blocking github-importer tickets
>> https://sourceforge.net/p/allura/tickets/6922/
>>> and https://sourceforge.net/p/allura/tickets/6993/ are now closed, so
>> we could
>>> do a release with all the importers enabled now.
>>>
>>> However I said [1] that we'd also remove a SourceForge reference on a
>> repo page
>>> before our next release, so I think we should do some work on
>>> https://sourceforge.net/p/allura/tickets/4808/
>>>
>>> [1]
>>>
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201311.mbox/%3C527D32D4.9000709%40brondsema.net%3E
>>>
>>> On 12/10/13 3:28 PM, Cory Johns wrote:
>>>> Agreed. Having all of our current importers enabled seems like a good
>> spot
>>>> to release, as does activity streams.
>>>>
>>>> I think we should try not to ever go more than 2 months without doing a
>>>> release, and I might even say 1 release per month might be a good target
>>>> though we can start with 2 and see how that goes.
>>>>
>>>>
>>>> On Tue, Dec 10, 2013 at 2:36 PM, Dave Brondsema <da...@brondsema.net>
>> wrote:
>>>>
>>>>> How frequently do we want to make Allura releases? Particularly when
>> do
>>>>> we want
>>>>> to make our next one - but we can talk in general terms too.
>>>>>
>>>>> I am thinking we should do one fairly soon. It took a while to get our
>>>>> first
>>>>> release out, but we now have a release script which should help
>> automate a
>>>>> lot
>>>>> and ensure we cover all the technical aspects. And I think we'll be
>> able
>>>>> to get
>>>>> the votes more easily now that we've gotten past the hurdle of the
>> first
>>>>> one.
>>>>> Also, the Incubator PMC (IPMC) has voted & invited me to join the IPMC
>> a
>>>>> little
>>>>> while ago, so I can cast a binding vote too.
>>>>>
>>>>> In general, I'd suggest we make releases after certain significant
>>>>> features are
>>>>> done, or after a few months if we're doing many small/medium changes
>> but
>>>>> nothing
>>>>> too big. Lately we've done a lot of work around Google, Trac, and
>> Github
>>>>> importers. IMO https://sourceforge.net/p/allura/tickets/6922/ is a
>>>>> blocker for
>>>>> github, but after that is fixed might be a good time to release.
>> Another
>>>>> big
>>>>> ongoing initiative is activity streams, which might make a good 3rd
>>>>> release).
>>>>>
>>>>> --
>>>>> Dave Brondsema : dave@brondsema.net
>>>>> http://www.brondsema.net : personal
>>>>> http://www.splike.com : programming
>>>>> <><
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Dave Brondsema : dave@brondsema.net
>> http://www.brondsema.net : personal
>> http://www.splike.com : programming
>> <><
>>
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: when to do a next Allura release?
Posted by Cory Johns <jo...@gmail.com>.
The release script will update, commit, and tag the CHANGELOG, and it will
build the artifacts and put them in /tmp/allura-incubating-$VERSON. You'll
need to push the CHANGELOG commit and tag, and move the artifacts to your
ASF repo dir and commit them, and of course make the mailing list thread.
I'm fine with 1.1.0. Third-party tools will only break if they don't use
EasyWidgets for their forms, right?
On Fri, Jan 24, 2014 at 4:11 PM, Dave Brondsema <da...@brondsema.net> wrote:
> With 4808 closed now, I think we're primed for our next release. I'm
> interested
> in running this one. I assume I can just run the scripts/asf-release.sh
> script
> that Cory wrote, right?
>
> We talked a bit about versioning, anyone have a strong feeling for what
> this one
> will be? Maybe I need to look at the changelog but I'm inclined for 1.1.0
> rather than 2.0.0 even though technically 3rd-party Allura tools may likely
> break, due to CSRF changes. Doesn't seem like a "big enough" breaking
> change to me.
>
> On 1/13/14 10:32 AM, Dave Brondsema wrote:
> > Blocking github-importer tickets
> https://sourceforge.net/p/allura/tickets/6922/
> > and https://sourceforge.net/p/allura/tickets/6993/ are now closed, so
> we could
> > do a release with all the importers enabled now.
> >
> > However I said [1] that we'd also remove a SourceForge reference on a
> repo page
> > before our next release, so I think we should do some work on
> > https://sourceforge.net/p/allura/tickets/4808/
> >
> > [1]
> >
> http://mail-archives.apache.org/mod_mbox/incubator-general/201311.mbox/%3C527D32D4.9000709%40brondsema.net%3E
> >
> > On 12/10/13 3:28 PM, Cory Johns wrote:
> >> Agreed. Having all of our current importers enabled seems like a good
> spot
> >> to release, as does activity streams.
> >>
> >> I think we should try not to ever go more than 2 months without doing a
> >> release, and I might even say 1 release per month might be a good target
> >> though we can start with 2 and see how that goes.
> >>
> >>
> >> On Tue, Dec 10, 2013 at 2:36 PM, Dave Brondsema <da...@brondsema.net>
> wrote:
> >>
> >>> How frequently do we want to make Allura releases? Particularly when
> do
> >>> we want
> >>> to make our next one - but we can talk in general terms too.
> >>>
> >>> I am thinking we should do one fairly soon. It took a while to get our
> >>> first
> >>> release out, but we now have a release script which should help
> automate a
> >>> lot
> >>> and ensure we cover all the technical aspects. And I think we'll be
> able
> >>> to get
> >>> the votes more easily now that we've gotten past the hurdle of the
> first
> >>> one.
> >>> Also, the Incubator PMC (IPMC) has voted & invited me to join the IPMC
> a
> >>> little
> >>> while ago, so I can cast a binding vote too.
> >>>
> >>> In general, I'd suggest we make releases after certain significant
> >>> features are
> >>> done, or after a few months if we're doing many small/medium changes
> but
> >>> nothing
> >>> too big. Lately we've done a lot of work around Google, Trac, and
> Github
> >>> importers. IMO https://sourceforge.net/p/allura/tickets/6922/ is a
> >>> blocker for
> >>> github, but after that is fixed might be a good time to release.
> Another
> >>> big
> >>> ongoing initiative is activity streams, which might make a good 3rd
> >>> release).
> >>>
> >>> --
> >>> Dave Brondsema : dave@brondsema.net
> >>> http://www.brondsema.net : personal
> >>> http://www.splike.com : programming
> >>> <><
> >>>
> >>
> >
> >
> >
>
>
>
> --
> Dave Brondsema : dave@brondsema.net
> http://www.brondsema.net : personal
> http://www.splike.com : programming
> <><
>
Re: when to do a next Allura release?
Posted by Dave Brondsema <da...@brondsema.net>.
With 4808 closed now, I think we're primed for our next release. I'm interested
in running this one. I assume I can just run the scripts/asf-release.sh script
that Cory wrote, right?
We talked a bit about versioning, anyone have a strong feeling for what this one
will be? Maybe I need to look at the changelog but I'm inclined for 1.1.0
rather than 2.0.0 even though technically 3rd-party Allura tools may likely
break, due to CSRF changes. Doesn't seem like a "big enough" breaking change to me.
On 1/13/14 10:32 AM, Dave Brondsema wrote:
> Blocking github-importer tickets https://sourceforge.net/p/allura/tickets/6922/
> and https://sourceforge.net/p/allura/tickets/6993/ are now closed, so we could
> do a release with all the importers enabled now.
>
> However I said [1] that we'd also remove a SourceForge reference on a repo page
> before our next release, so I think we should do some work on
> https://sourceforge.net/p/allura/tickets/4808/
>
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-general/201311.mbox/%3C527D32D4.9000709%40brondsema.net%3E
>
> On 12/10/13 3:28 PM, Cory Johns wrote:
>> Agreed. Having all of our current importers enabled seems like a good spot
>> to release, as does activity streams.
>>
>> I think we should try not to ever go more than 2 months without doing a
>> release, and I might even say 1 release per month might be a good target
>> though we can start with 2 and see how that goes.
>>
>>
>> On Tue, Dec 10, 2013 at 2:36 PM, Dave Brondsema <da...@brondsema.net> wrote:
>>
>>> How frequently do we want to make Allura releases? Particularly when do
>>> we want
>>> to make our next one - but we can talk in general terms too.
>>>
>>> I am thinking we should do one fairly soon. It took a while to get our
>>> first
>>> release out, but we now have a release script which should help automate a
>>> lot
>>> and ensure we cover all the technical aspects. And I think we'll be able
>>> to get
>>> the votes more easily now that we've gotten past the hurdle of the first
>>> one.
>>> Also, the Incubator PMC (IPMC) has voted & invited me to join the IPMC a
>>> little
>>> while ago, so I can cast a binding vote too.
>>>
>>> In general, I'd suggest we make releases after certain significant
>>> features are
>>> done, or after a few months if we're doing many small/medium changes but
>>> nothing
>>> too big. Lately we've done a lot of work around Google, Trac, and Github
>>> importers. IMO https://sourceforge.net/p/allura/tickets/6922/ is a
>>> blocker for
>>> github, but after that is fixed might be a good time to release. Another
>>> big
>>> ongoing initiative is activity streams, which might make a good 3rd
>>> release).
>>>
>>> --
>>> Dave Brondsema : dave@brondsema.net
>>> http://www.brondsema.net : personal
>>> http://www.splike.com : programming
>>> <><
>>>
>>
>
>
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><