You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by James Dailey <jd...@apache.org> on 2024/03/15 15:06:02 UTC
Release 1.9.1
Devs
I’d like to propose that we get out a release 1.9.1 with recent changes by
April 9th. I’m willing to serve as release manager although I’ll need
support.
Let’s make sure we have stable code for a snapshot on April 3rd. If
someone has a better date , please let me know.
The strategy should be quarterly releases so that we don’t end up with such
massive reviews.
At all times the dev branch should be in a stable condition and passing all
tests. When it is not, then someone should be working on it actively to
correct the situation.
Sent from Gmail Mobile
Re: Release 1.9.1
Posted by James Dailey <jd...@apache.org>.
Moving forward with this tomorrow. I'm assuming all is ok.
Let me know if not.
On Thu, Mar 21, 2024 at 10:50 PM James Dailey <jd...@apache.org> wrote:
> Terrific - I will lean on you both for support.
>
> The plan of action is to try to tag a release in Github on April 9th.
> Then there should be validation of that, then a vote, then a formal
> release.
> Release should be within a few days to a week after April 9th if all goes
> to plan.
>
> Tickets that are open but not being worked on should move to the
> theoretical release 1.10.0.
> I'll run a batch update on the jira tickets.
>
> I'll also close and archive tickets that are NOT being worked on recently
> (since release 1.9.0 date of early Jan). It makes no sense to have
> hundreds of open tickets that no one is working on, and difficult to know
> if the tickets are valid unless they've been created recently. So, grab a
> ticket if you want and keep it alive. You have until April 8th. Grab a
> few, grab many.
>
> Open and in process tickets - please let me know a week in advance. We
> can accommodate a shift in dates... just need to know what's going on. I
> would ask that you try to keep things especially stable on April 8-10th,
> but we can move this a week later or so. Again, I'm trying to set the date
> - so speak up.
>
> Also, I am assuming that all PRs are properly following the checklist
> which includes test coverage, coding standards, and reference to a jira
> ticket. This last one is essential for traceability of the code changes,
> and I'll be looking for adherence to this policy. i.e. you can expect a
> reaction if you haven't managed this basic thing, so please check.
>
> For any of this, I'm open to being overruled by a vocal group of
> contributors, so let me know if this seems wrong in any way. I'm not
> dictating, just trying to move this forward, and I take silence as
> acquiescence.
>
> Thanks,
>
>
>
>
>
> On Fri, Mar 15, 2024 at 12:59 PM Inzemamul Haq <in...@gmail.com>
> wrote:
>
>> I can too assist...
>>
>> On Sat, 16 Mar, 2024, 1:25 am Aleksandar Vidakovic, <
>> cheetah@monkeysintown.com> wrote:
>>
>>> ... can assist
>>>
>>> On Fri, Mar 15, 2024 at 4:09 PM James Dailey <jd...@apache.org> wrote:
>>>
>>>> Devs
>>>>
>>>> I’d like to propose that we get out a release 1.9.1 with recent changes
>>>> by April 9th. I’m willing to serve as release manager although I’ll need
>>>> support.
>>>>
>>>> Let’s make sure we have stable code for a snapshot on April 3rd. If
>>>> someone has a better date , please let me know.
>>>>
>>>> The strategy should be quarterly releases so that we don’t end up with
>>>> such massive reviews.
>>>>
>>>> At all times the dev branch should be in a stable condition and passing
>>>> all tests. When it is not, then someone should be working on it actively
>>>> to correct the situation.
>>>>
>>>>
>>>>
>>>> Sent from Gmail Mobile
>>>>
>>>
Re: Release 1.9.1
Posted by James Dailey <jd...@apache.org>.
Terrific - I will lean on you both for support.
The plan of action is to try to tag a release in Github on April 9th.
Then there should be validation of that, then a vote, then a formal
release.
Release should be within a few days to a week after April 9th if all goes
to plan.
Tickets that are open but not being worked on should move to the
theoretical release 1.10.0.
I'll run a batch update on the jira tickets.
I'll also close and archive tickets that are NOT being worked on recently
(since release 1.9.0 date of early Jan). It makes no sense to have
hundreds of open tickets that no one is working on, and difficult to know
if the tickets are valid unless they've been created recently. So, grab a
ticket if you want and keep it alive. You have until April 8th. Grab a
few, grab many.
Open and in process tickets - please let me know a week in advance. We
can accommodate a shift in dates... just need to know what's going on. I
would ask that you try to keep things especially stable on April 8-10th,
but we can move this a week later or so. Again, I'm trying to set the date
- so speak up.
Also, I am assuming that all PRs are properly following the checklist which
includes test coverage, coding standards, and reference to a jira ticket.
This last one is essential for traceability of the code changes, and I'll
be looking for adherence to this policy. i.e. you can expect a reaction if
you haven't managed this basic thing, so please check.
For any of this, I'm open to being overruled by a vocal group of
contributors, so let me know if this seems wrong in any way. I'm not
dictating, just trying to move this forward, and I take silence as
acquiescence.
Thanks,
On Fri, Mar 15, 2024 at 12:59 PM Inzemamul Haq <in...@gmail.com>
wrote:
> I can too assist...
>
> On Sat, 16 Mar, 2024, 1:25 am Aleksandar Vidakovic, <
> cheetah@monkeysintown.com> wrote:
>
>> ... can assist
>>
>> On Fri, Mar 15, 2024 at 4:09 PM James Dailey <jd...@apache.org> wrote:
>>
>>> Devs
>>>
>>> I’d like to propose that we get out a release 1.9.1 with recent changes
>>> by April 9th. I’m willing to serve as release manager although I’ll need
>>> support.
>>>
>>> Let’s make sure we have stable code for a snapshot on April 3rd. If
>>> someone has a better date , please let me know.
>>>
>>> The strategy should be quarterly releases so that we don’t end up with
>>> such massive reviews.
>>>
>>> At all times the dev branch should be in a stable condition and passing
>>> all tests. When it is not, then someone should be working on it actively
>>> to correct the situation.
>>>
>>>
>>>
>>> Sent from Gmail Mobile
>>>
>>
Re: Release 1.9.1
Posted by Inzemamul Haq <in...@gmail.com>.
I can too assist...
On Sat, 16 Mar, 2024, 1:25 am Aleksandar Vidakovic, <
cheetah@monkeysintown.com> wrote:
> ... can assist
>
> On Fri, Mar 15, 2024 at 4:09 PM James Dailey <jd...@apache.org> wrote:
>
>> Devs
>>
>> I’d like to propose that we get out a release 1.9.1 with recent changes
>> by April 9th. I’m willing to serve as release manager although I’ll need
>> support.
>>
>> Let’s make sure we have stable code for a snapshot on April 3rd. If
>> someone has a better date , please let me know.
>>
>> The strategy should be quarterly releases so that we don’t end up with
>> such massive reviews.
>>
>> At all times the dev branch should be in a stable condition and passing
>> all tests. When it is not, then someone should be working on it actively
>> to correct the situation.
>>
>>
>>
>> Sent from Gmail Mobile
>>
>
Re: Release 1.9.1
Posted by Aleksandar Vidakovic <ch...@monkeysintown.com>.
... can assist
On Fri, Mar 15, 2024 at 4:09 PM James Dailey <jd...@apache.org> wrote:
> Devs
>
> I’d like to propose that we get out a release 1.9.1 with recent changes by
> April 9th. I’m willing to serve as release manager although I’ll need
> support.
>
> Let’s make sure we have stable code for a snapshot on April 3rd. If
> someone has a better date , please let me know.
>
> The strategy should be quarterly releases so that we don’t end up with
> such massive reviews.
>
> At all times the dev branch should be in a stable condition and passing
> all tests. When it is not, then someone should be working on it actively
> to correct the situation.
>
>
>
> Sent from Gmail Mobile
>