There is a release checklist here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ReleaseCheckList
Some of the work involves the buildmaster, so I think either Seb will have to do
some of that or give someone else access to do it.
The live image does need to be made as well.
Another thing that will require some work is documenting all the changes from
2.7 to 2.8
You may be right about mailing list over IRC. Taking a few days to discuss
something is probably not bad though.
Moses
On 5/30/19 8:26 AM, John Thornton wrote:
Yep lets do it!
What else has to be done to get the release out after creating the branch?
I assume we need to have a 2.8 LiveDVD at some point?
I think timing is an issue for IRC meetings, one advantage to the mailing list
is you don't have to be there at any specific time. The disadvantage is it can
take a few days to discuss something on the mailing list.
JT
On 5/29/2019 8:04 PM, Moses McKnight wrote:
Hi All,
It seems that there is somewhat of a consensus to release 2.8 with it's
current features plus bugfixes.
This means that major features such as reverse run would not be in 2.8, but
would be merged into master as soon as 2.8 is branched off.
So this is kind of a last call for comments - if a majority are for it then I
or someone will create the 2.8 branch in the next few days.
Rob had some good ideas for improving on releases:
On 5/21/19 4:53 PM, Robert Ellenberg wrote:
FWIW, I would also like a more formal release schedule. The team has done a
good job of pushing out point releases for 2.7, but it seems like 2.8 is an
ever-receding goal. Some ideas for how to improve:
- Periodic dev meetings (IRC or via videoconference) to set milestones
and document our decisions (so we're not constantly second guessing
ourselves or having to re-answer the same questions).
- Identify some areas of expertise and/or responsibility (and list them
publicly) so that contributors know who to include in their pull requests /
code reviews. Bugs in can be assigned to experts to triage / fix, or
delegate to someone who can.
- Expand test coverage, particularly unit tests. I have some tests
implemented in my branches (basic tests for TP and interp), but this would
be a long-term effort to get wide coverage, particularly in rarely-touched
code
As far as a formal release schedule - I guess we could just say something like
a major release every year and point releases 4 times a year? I suppose
having a schedule and missing or skipping release dates now and again is
better than not having a schedule.
There used to be some periodic dev meetings on IRC. I can't remember why we
quit, but it seemed like there wasn't a whole lot discussed in the few I was
able to be in. I would vote we start them back up and I would prefer IRC.
The main thing is that someone would need to do the documenting and we would
have to have a place to do that (wiki, github issues etc?).
In any case, hopefully we can release the next major version much sooner than
this one has taken.
Moses
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
--
And as it is appointed unto men once to die, but after this the judgment:
So Christ was once offered to bear the sins of many; and unto them that look
for him shall he appear the second time without sin unto salvation.
(Hebrews 9:27-28)
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
