[Ohrrpgce] Quarterly Stable Releases?

Tue Jul 18 09:55:41 PDT 2017

On 17 July 2017 at 10:16, James Paige <Bob at hamsterrepublic.com> wrote:

>
>
> On Sun, Jul 16, 2017 at 6:22 PM, Ralph Versteegen <teeemcee at gmail.com>
> wrote:
>
>>
>>
>> On 16 July 2017 at 15:15, James Paige <Bob at hamsterrepublic.com> wrote:
>>
>>>
>>>
>>> On Sat, Jul 15, 2017 at 8:28 PM, Ralph Versteegen <teeemcee at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 15 July 2017 at 16:32, James Paige <Bob at hamsterrepublic.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sat, Jul 15, 2017 at 7:48 AM, Ralph Versteegen <teeemcee at gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 13 July 2017 at 22:14, James Paige <Bob at hamsterrepublic.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jul 13, 2017 at 5:55 PM, Ralph Versteegen <
>>>>>>> teeemcee at gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 14 July 2017 at 02:15, James Paige <Bob at hamsterrepublic.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I agree that potential backcompat problems also belongs in the
>>>>>>>>> category of reaons-to-delay-a-release
>>>>>>>>>
>>>>>>>>> Lets work for a 3-month release schedule. i won't fix it to
>>>>>>>>> specific months, I'll just set up reminders for the next one 3 months after
>>>>>>>>> each time we actually do a release.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Sounds agreeable, and hopefully we'll have better discipline than
>>>>>>>> we've had for the last decade!
>>>>>>>>
>>>>>>>
>>>>>>> I have a good feeling about it this time :D
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I would like to still aim for an RC in the first week of August,
>>>>>>>>> if possible.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'll be in Australia for two weeks from August 7th, and though I'll
>>>>>>>> take my netbook it would be better if the RC were earlier rather than later.
>>>>>>>>
>>>>>>>
>>>>>>> Duly noted! Earlier rather than later!
>>>>>>>
>>>>>>
>>>>>> Well, this isn't a RC yet, is it? Might have be a teeny bit early
>>>>>> since there's a bunch of stuff to do. I'm hoping I'll be free within a week
>>>>>> to do significant OHR work. I'm trying to finish my thesis right now.
>>>>>>
>>>>>>
>>>>> No, not yet, just soon-ish.
>>>>>
>>>>> And don't let this distract you from your thesis! We are officially
>>>>> adding Thesises to the list of valid reasons to delay a release ;)
>>>>>
>>>>>
>>>>>> I've trimmed down my TODO list for Dwimmercrafty. Here's what's left,
>>>>>> including a bunch of nearly-finished features which I expect to be able to
>>>>>> finish off in a couple days:
>>>>>>
>>>>>> Serious bugs:
>>>>>> -fix broken frameskipping dropping frames as you get near 60fps.
>>>>>> Causes Mac to run at 30fps.
>>>>>>  And bad fps setting interaction with vsync, should tweak dowait a
>>>>>> little (still true?). No problem in fullscreen
>>>>>> -"! Unsupported default tile passability format" on e.g. POWERXE.RPG
>>>>>> week 383 map 107 Botsmir Forest
>>>>>>  Also happens in the OHRCEtutorial2017.rpg file Lisa sent 21/6/17
>>>>>>  Seems to indicate data loss?
>>>>>>
>>>>>
>>>>> I if all of those existed in callipygous, they don't need to be
>>>>> dwimmercraftly blockers-- but yes, they do sound very important
>>>>>
>>>>
>>>> All the bugs I've listed are new in the last half a year or so. (In
>>>> fact I probably introduced all of them!)
>>>> I think that the default wall error message was introduced at the same
>>>> time that I changed loadrecord's handling of partially missing records. I
>>>> see that what I changed was what loadrecord returns in that case (as well
>>>> as adding an error message). I haven't investigated this yet.
>>>>
>>>>
>>>>>
>>>>>
>>>>>> -fridge racer graphics completely broken when compiled with scons
>>>>>> debug=3!!!
>>>>>>
>>>>>
>>>>> What is our default debug level for releases?
>>>>>
>>>> debug=0. But I have learnt from experience that unexpected bugs are
>>>> often indicative of bigger underlying problems that haven't been noticed
>>>> yet. A bug that only appears with debug=3 is probably a Heisenbug, and
>>>> Heisenbugs never really go away, they just hide from view!
>>>>
>>>>>
>>>>>
>>>>>> -update innosetup for data/ (.exe installer doesn't install correct)
>>>>>>
>>>>>
>>>>> If you haven't started already, I can that that one.
>>>>>
>>>>>
>>>>>> -fix new zone corruption bug (and finish zone testcases)
>>>>>> -some serious Ctrl-F12 bug on windows. With gifsicle present, lots of
>>>>>> cmd.exe windows
>>>>>>  pop up and F12 remains stuck until interact with window. gfx_sdl.
>>>>>> --Problem holding down F12 for a second: "Saved  and 60 more" Only
>>>>>> happens first time?
>>>>>>
>>>>>
>>>> My plan to fix this was just to remove the ability to take multiple
>>>> screenshots by holding down F12. It was such a waste of time to implement
>>>> that.
>>>> Still, cmd.exe windows shouldn't be popping up at all; probably I'm
>>>> spawning gifsicle in the wrong way. Obviously not a blocker.
>>>>
>>>>
>>>
>>> Yeah, that is good. holding down F12 is 100% obsoleted by CTRL+F12
>>> animated gifs, no need to keep it around.
>>>
>>>
>>>
>>>> -merge forgotten elemental_fix dataloss bugfix
>>>>>> -fix various gdebug loadrecord errors (may cause corruption due to
>>>>>> now refusing to read?)
>>>>>> --in particular at end of file when importing scripts
>>>>>>
>>>>>> Other bugs:
>>>>>> -finish fixing total joystick brokenness
>>>>>> -mac fullscreen zoom selection wonkiness (WillyElectrix)
>>>>>>
>>>>>
>>>>> Do we know if fullscreen has ever worked correct on Mac? I can't
>>>>> actually remember if I ever tested it.
>>>>>
>>>>
>>>> Yes, it always used to work correctly. I still remember getting it
>>>> working back in 2010.
>>>> I think this is a combination of later OSX versions working a bit
>>>> differently, the engine now attempting to resize the window when entering
>>>> the game,  the way gfx_sdl selects zoom being bad, and maybe my recent
>>>> changes.
>>>>
>>>>>
>>>>>
>>>>>> -finish/merge fix for the glitched text colour in the slice
>>>>>> collection editor
>>>>>> -fix find_file_portably to disallow varous filename characters
>>>>>> --more checks on filenames in rungame(), and check both .rpg and
>>>>>> .rpgdir
>>>>>>
>>>>>> Other:
>>>>>> -set "Touch textboxes" on by default.
>>>>>>
>>>>>
>>>>> I'll do that one, it has been on my own to-do list a few weeks
>>>>>
>>>>>
>>>>>> -make suspendboxadvance stop choicebox controls too
>>>>>>
>>>>>
>>>>> That seems strange to me. What is the reason for that one?
>>>>>
>>>>
>>>> suspendboxadvance stops the use key from selecting one of the choices,
>>>> but doesn't block the up/down/etc keys, which is rather weird. Especially
>>>> if there's also a menu up.
>>>>
>>>
>>> Oh, yeah, now I understand.
>>>
>>> Okay, I can take care of that one.
>>>
>>>
>>>>
>>>>>
>>>>>> -pref bitset to close textbox with esc
>>>>>>
>>>>>
>>>>> I can do that one.
>>>>>
>>>>>
>>>>>> -finalise a* limits and npc obstr handling
>>>>>>
>>>>>
>>>>> I'll definitely finalize the ability to support different modes of
>>>>> obstruction handling, but we don't have to finish every mode, since we can
>>>>> add other modes later.
>>>>>
>>>>
>>>> Having an option for different modes could be added any time, so that's
>>>> not a blocker anyway.
>>>>
>>>> "Finalise limits" referred to whether we want to make max_search
>>>> default to more than 1000 now that it's faster.
>>>>
>>>
>>> 1000 seems pretty good, I am okay with it.
>>> That was another limit I was thinking about being able to set on and
>>> npc-by-npc basis
>>>
>>>
>>>>
>>>> I expected that there would be various experiments or tweaks we might
>>>> want to do.
>>>>
>>>> This reminds me of an example. In the swarm maps in a-star.rpg, if
>>>> you're surrounded by slimes only the immediately adjacent ones animate,
>>>> walking into you. Why is that? How do 'dumb' Chase NPCs behave?
>>>>
>>>
>>> I think colliding with the hero doesn't stop them from trying to
>>> complete the movement. Colliding with walls and other npcs makes them give
>>> up.
>>>
>>> I'll have to check what dumb chase ncps do.
>>>
>>> Probably it would be more correct for pathfinding npcs to stop animating
>>> when they reach the hero, just like when they hit other obstructions.
>>>
>>>
>>>>
>>>> Another thing. I was wondering whether the way 'consolidation' tile
>>>> picked is the right way to go. Currently it picks a tile that's the closest
>>>> to the target. But maybe it should take into account how long the path to
>>>> that tile is. E.g. if you're currently 4 tiles from the destination, but
>>>> could go around a long way to get within 3 tiles, should you move? Maybe it
>>>> depends on whether max_search was hit?
>>>>
>>>
>>> Oh... Hmmm. I don't know.
>>>
>>> I think the current behavior is okay-- and if we come up with some other
>>> alternatives, we can add a choice of "Consolation tile algorithm"
>>>
>>
>> Pathing to a 'reasonable' tile instead of the absolute-closest-to-target
>> should also reduce the behaviour of crowds of slimes dithering between two
>> extremes. The problem is that the consolation behaviour is sort of
>> inconsistent with the behaviour when there is a path: it doesn't care at
>> all about how long the path is (aside from as tie-break), even though it's
>> meant to be an algorithm to find the shortest path! Well, to be fair,
>> exactly the same thing would happen if you're currently 2 tiles away
>> because an NPC is in the way and you can go around a long way to get within
>> 1 tile.
>> Actually, both cases could be handled the same way: use "path length +
>> closest achievable distance to goal * 10" as the cost.
>>
>
> So if I understand correctly, in the consolation tile code, instead of
> using best_closed_node->p as the consolation tile, I should instead do one
> more sort of the closedlist based on "path length + closest achievable
> distance to goal * 10" where closest achievable distance from goal is the
> number of tiles between best_closed_node->p and the goal, right?
>

The closed list isn't explicitly stored anymore. If you want to change
which node gets picked as consolation, you need to change
closed_node_compare().

Also note that while closed_node_compare currently uses cost_after_squared
(aka dist_squared), you can't mix the squared distance with the cost_before
distance without doing a squareroot, which would be way too slow. So just
switch to cost_after. There's no real need to use distance squared; that's
more important as a tiebreak when comparing open nodes to ensure diagonal
paths are taken.

Oh! I just noticed a bug: the best consolation tile isn't picked while
taking map wrapping into account. Which means an NPC might actually path to
the furthest away tile instead of the nearest! cost_after and dist_squared
are meant to be nearly the same, except one involves squares. (Actually,
they're so similar that it would be simpler and faster to compute them at
the same time)
Ok, so I went and did that. And then tried out consolation tile picking in
the a-star.rpg wrapping map using F11. And to my horror, when I walked into
a wall, the NPC pathed to the furtherest away tile from the hero, every
time! the very bug I thought I just fixed! It turns out that there was a
second bug.

Anyway after trying it out, I definitely think that "being lazy" should be
a pathfinding behavioural option (i.e not pathing a long distance just to
get slightly closer). And using dist_squared only makes it worse, since the
consolation tile is often not closer, but just "more diagonal"! People
typically aren't going to want this.

>
>
>
>>
>>>
>>>>
>>>>
>>>>>
>>>>>> -whatsnew: mention Custom mouse improvements
>>>>>> -whatsnew: mention NPC pathfinding options
>>>>>> -whatsnew: mention FreeBSD
>>>>>> -whatsnew: zzo38's attack options?
>>>>>>
>>>>>
>>>>> Probably best to leave those unmentioned until they have some gui
>>>>> hooked up to them
>>>>>
>>>>
>>>> Yes, I agree. Unless they go in the 'Stuff for Developers'
>>>>
>>>>>
>>>>>
>>>>
>>>>>
>>>>>> -find out why windows builds now much larger
>>>>>> -upload hsdecmpl and chgpal
>>>>>>
>>>>>> Nearly finished features:
>>>>>> -merge git branches:
>>>>>> --browse32
>>>>>> --bmp import stuff
>>>>>> --better minimap
>>>>>> --mouse wheel script commands
>>>>>> --better unicode input
>>>>>> --script warnings/plotdict improvements
>>>>>> --ui colour constants
>>>>>> ---change various script commands to allow them
>>>>>> --new equip merge formula
>>>>>> --scrolling in show_help and multiline editor
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am not worried about finishing the hero mouse controls before
>>>>>>>>> Dwimmercrafty. I don't expect them to be ready to move out of the spam menu
>>>>>>>>> by then, but I don't feel the need to disable them any further either.
>>>>>>>>>
>>>>>>>>> I actually feel pretty good about NPC pathfinding right now. Good
>>>>>>>>> enough to remove the "EXPERIMENTAL" from the menu caption in the NPC
>>>>>>>>> editor. Are there any other aspects of it you would like to see me clean up
>>>>>>>>> before dwimmercrafty, especially in the avoiding-backcompat-problems
>>>>>>>>> department?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hero pathfinding isn't any problem. I was just concerned about
>>>>>>>> finalising how NPC pathfinding works, in particular the treatment of other
>>>>>>>> NPCs as obstacles. You added NPCInst.stillticks but it's used only for
>>>>>>>> pathfindnpcto/npcchasesnpc's stop after still ticks. I thought the idea was
>>>>>>>> to also use it to set the penalty for pathing through that NPC.
>>>>>>>>
>>>>>>>
>>>>>>> Ah, yes. Well, I want to be able to choose between different modes,
>>>>>>> and the current mode of treating all npcs like moving walls is definitely
>>>>>>> one of those modes. I also want a mode that treats all NPCs as completely
>>>>>>> passable. That will often lead to getting stuck, but I think for some
>>>>>>> purposes it will be just what you want. A smarter mode that increases path
>>>>>>> cost for NPCs in the way is definitely needed also.
>>>>>>>
>>>>>>> I don't think all those modes need to be finished before
>>>>>>> dwimmercrafty. I don't see any backcompat problems because the current mode
>>>>>>> will still exist as an option even after the other modes are added, and the
>>>>>>> tread-everything-as-walls mode is probably the most intuitive default (even
>>>>>>> if it happens to be less optimal)
>>>>>>>
>>>>>>
>>>>>> Ah. I wasn't sure whether those other modes would be useful. Having
>>>>>> branches in the code to support worse ways to do pathfinding seems a lot
>>>>>> like backcompat cruft.
>>>>>>
>>>>>
>>>>> Well, I have been reading various tutorials about A*, and one thing I
>>>>> have learned is that there definitely is no possible one-size-fits-all
>>>>> ideal way to handle obstruction from moving units. Most of what I have read
>>>>> recommends one or the other extreme, hence the first two modes.
>>>>>
>>>>> For the smarter mode that considers how long a unit has been
>>>>> stationary, there is a lot of room for fine tuning. At the bare minimum, I
>>>>> think that one is going to require at least one more configuration option.
>>>>> I expect that this mode won't be ready before dwimmercrafty, but I'll
>>>>> definitely get the other two implemented.
>>>>>
>>>>
>>>> Yes, it will definitely want tuning, so best to have time to do that.
>>>>
>>>>>
>>>>> I like the way the current mode obstructs, and I think it will be a
>>>>> good default, even if it isn't right for every purpose.
>>>>>
>>>>>
>>>>>> But I perhaps sometimes you want your little slimes to run back and
>>>>>> forth helplessly confused!
>>>>>> Another potential mode was to be smart about not throwing away and
>>>>>> recomputing paths every step (which I would have hoped would be the
>>>>>> default).
>>>>>>
>>>>>
>>>>> Oh! Thank you for reminding me.
>>>>>
>>>>> I think it will be called "Pathfind steps at a time:" and default to 1.
>>>>>
>>>>> The NPC instance will keep a small vector of planned steps and use
>>>>> them before it pathfinds again. if it collides with anything, it can throw
>>>>> them away and try again
>>>>>
>>>>> I'll also need an argument for "pathfind npc to" that sets this.
>>>>>
>>>>> This sounds fun, hopefully I'll have time to do it soon.
>>>>>
>>>>
>>>> You may want to force the steps to 1 if the path is short (and
>>>> therefore cheap to compute anyway), to keep it optimal.
>>>> Having done that, it may be feasible to default to 2-4 instead.
>>>>
>>>
>>> Good idea!
>>>
>>> I could actually have 2 options,
>>>
>>> Pathfind X steps at a time if path is longer than Y steps
>>>
>>
>> This is starting to sound like far too many settings! I don't want to
>> overload people with technical details. The settings should aim to be for
>> the behaviour of the NPCs, not how that is accomplished; I'd rather err on
>> the side of not exposing parameters that aren't very useful. Useful
>> behaviour settings include for example bunching behaviour (whether to bunch
>> up on one side of a bottle neck, or split up and try to surround the player
>> from every side) and how hard to search for a path (max_search). Pathing X
>> steps at a time was meant to be an optimisation which changes the behaviour
>> as little as possible. The only visible effect it should have is how often
>> an NPC changes direction if a path opens/closes. I'm not sure that matters.
>>
>
> Yeah, perhaps "Pathfind X steps at a time if path is longer than Y steps"
> doesn't make a good user-exposed option. I could implement it with some
> guesses at good values (maybe "Pathfind 4 steps at a time if path is longer
> than 40 steps")
>

X=2 already halves the amount of computation, and it's diminishing returns
from there. *shrug*

>
> If anybody finds a good reason they need some other behavior, we can add
> an option to override that later.
>
>>
>>
>> When pathing X steps at a time, we could recompute the path if an
>> unexpected obstacle is hit OR the map changes OR the target moves, where
>> "the map changes" can include the movement of previously obstructing NPCs.
>> For example we could record a list of NPCs encountered (probably limited to
>> nearby ones) and their positions in a vector and pass it back. Checking
>> whether they've moved is hugely cheaper than recomputing the path. However
>> it makes it likely that the path will be thrown away. Which means this is a
>> lot of work for an optimisation that's going to provide no speed up at all
>> when things go wrong.
>>
>>
> I was already planning to recompute if an unexpected obstacle is hit, or
> if the target moves.
>
> checking if a previously obstructing npc has moved sounds like more
> trouble than it is worth, I don't think I will attempt that.
>

It certainly is a lot of trouble. (Reminds me that I once spent a month
working an incredibly overcomplicated optimised A*  which precomputed all
deadends and the paths between them... and deadends can be inside other
deadends, etc. I learnt my lesson!)

A very simple but maybe not too useful alternative is for pathfinding to
record how far it was to the nearest obstructing NPC, and then reduce X to
no more than this. This would force it to recompute the path each step when
circling around NPCs which might have already moved out of the way, causing
''laggy dodging".

>
>
>
>
>> Just occurred to me that tweaking pathfinding will break replays. Which
>> were always going to break between different engine versions anyway, but I
>> was hoping they would break infrequently.
>> (But we don't want the extra shackles of trying to keep replays working!)
>>
>
> Yeah, I can live with that. For me, the most important feature of replays
> is being able to (A) detect unplanned changes between two subsequent
> versions, and (B) visualize the consequences of planned changes between two
> versions.
>

I'm actually surprised by those reasons. But that will definitely be
useful.

>
> I am already resigned to the fact that I will need to re-create new
> recordings frequently (another reason I love the idea of having robust
> save/load supporting replays that I can record by default every time I am
> playing just for fun)
>
>
>>
>> I think a lot of the settings ought to be per-map rather than per-NPC,
>> because how you adjust them would depend on the complexity of pathing on
>> that map.
>>
>
> Possibly so. For the "NPC pathfinding obstruction rules" that I am working
> on right now, I should make a per-map default and an per-npc override.
>
> It isn't that much work to do both, since general map data and npc def
> data are both relatively painless to extend.
>

I see you prefer flexibility over "worse is better" simplicity!

>
>
>
>>
>>
>>
>>>
>>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> Also, the npc_ccache is populated by placing each NPC at the nearest
>>>>>>>> tile, which is different from how collision checking actually works (which
>>>>>>>> is to add x/ygo to get the tile being moved to), and I wonder whether that
>>>>>>>> matters.
>>>>>>>>
>>>>>>>
>>>>>>> Oh! Good catch. I'll fix that. Probably doesn't break anything being
>>>>>>> the way it is, but better to make it more correct.
>>>>>>>
>>>>>>
>>>>>> I actually suspected that the previous wrong way would look better,
>>>>>> since if you have a row of NPCs stuck after each other, each would begin to
>>>>>> move after the one in front has moved after a step. In theory. Actually,
>>>>>> it's hard to see the difference.
>>>>>>
>>>>>
>>>>> Agreed. It is a pretty subtle difference
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Also, there were one or two more optimisations I wanted to make
>>>>>>>> (though I'm mostly done with that). Unfortunately anything that changes
>>>>>>>> tile breaking or max-search handling even slightly is a potential change to
>>>>>>>> behaviour in edge cases.
>>>>>>>>
>>>>>>>
>>>>>>> That is true. I think that the documentation for pathfinding will
>>>>>>> need to mention the possibility that exact paths calculated aren't
>>>>>>> guaranteed to be identical in different versions.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I know vehicle pathfinding and pushing-npcs still need work, but
>>>>>>>>> those are both hero-pathfinding issues, not NPC pathfinding issues.
>>>>>>>>>
>>>>>>>>> On Wed, Jul 12, 2017 at 10:35 PM, Ralph Versteegen <
>>>>>>>>> teeemcee at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> I trust you saw my reply on SS already.
>>>>>>>>>> My two comments were that first, I'm not sure about a strict
>>>>>>>>>> schedule, and second that we should also hold up releases for anything that
>>>>>>>>>> could cause backcompat problems. Although as you say, we're generally good
>>>>>>>>>> about keeping unfinished features disabled or out of sight. For example
>>>>>>>>>> right now I would refuse a release until pathfinding is better nailed down.
>>>>>>>>>>
>>>>>>>>>> Also, doing release candidates is a good. So the actual release
>>>>>>>>>> date is whenever the RC is ready.
>>>>>>>>>>
>>>>>>>>>> Although we've been really active the last 7 months or so, we
>>>>>>>>>> have sometimes gone couple month without doing any substantial work on the
>>>>>>>>>> engine. Sometimes no commits for over a month. At our current activity
>>>>>>>>>> level a 3 month release cycle could even be too long, while other times
>>>>>>>>>> there wouldn't anything to release.
>>>>>>>>>> Lets take a look..
>>>>>>>>>> http://tmc.castleparadox.com/ohr/gitstats/activity.html
>>>>>>>>>>
>>>>>>>>>> And what if we want to release in less than 3 months after the
>>>>>>>>>> last release? Sometimes we might want to release while things are stable,
>>>>>>>>>> before starting on something destabilising.
>>>>>>>>>>
>>>>>>>>>> I was hoping that we would release Dwimmercrafty this month, but
>>>>>>>>>> actually with only two weeks left even a RC at the end of the month may be
>>>>>>>>>> unlikely.
>>>>>>>>>>
>>>>>>>>>> I don't remember if we've ever set a schedule for a release "X
>>>>>>>>>> months from now" rather than just near-term ones like "2 weeks from now". I
>>>>>>>>>> think being able to see from months away when we want the next release to
>>>>>>>>>> occur will be very helpful, and that we can manage to stick to it.
>>>>>>>>>>
>>>>>>>>>> On 13 July 2017 at 06:40, James Paige <Bob at hamsterrepublic.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I mentioned this once already in a thread on on slimesalad, but
>>>>>>>>>>> I thought this might be a better place to discuss the idea.
>>>>>>>>>>>
>>>>>>>>>>> I was thinking we should switch to a quarterly stable release
>>>>>>>>>>> schedule, rather than a whenever-we-feel-everything-im
>>>>>>>>>>> portant-that-we-wanted-to-add-has-been-finished schedule.
>>>>>>>>>>>
>>>>>>>>>>> We could do an August/November/February/May rotation, where I
>>>>>>>>>>> would branch and upload the stable release some day on the first full week
>>>>>>>>>>> of each of those months.
>>>>>>>>>>>
>>>>>>>>>>> I can set up a calendar alert that goes to this mailing list to
>>>>>>>>>>> warn us when the next release is 1 and 2 weeks away, so we have time to
>>>>>>>>>>> wrap up last minute stuff.
>>>>>>>>>>>
>>>>>>>>>>> The only things that would block a release would be critical or
>>>>>>>>>>> datalossy bugs, or other substantial problems that would make a new stable
>>>>>>>>>>> release measurably less stable than the previous one.
>>>>>>>>>>>
>>>>>>>>>>> Half finished features would not be an excuse to delay a
>>>>>>>>>>> release, because honestly, this whole program is a big beautiful muddy wad
>>>>>>>>>>> of half-finished features, and it always has been and it always will be,
>>>>>>>>>>> and I wouldn't have it any other way ;)
>>>>>>>>>>>
>>>>>>>>>>> I think we have actually been doing a pretty good job of keeping
>>>>>>>>>>> the nightly wip versions safe and stable, keeping the unfinished stuff more
>>>>>>>>>>> or less comfined to the "spam" menu, so I think this change is pretty
>>>>>>>>>>> low-risk.
>>>>>>>>>>>
>>>>>>>>>>> Thoughts?
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Ohrrpgce mailing list
>>>>>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>>>>>>> amster.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Ohrrpgce mailing list
>>>>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>>>>>> amster.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Ohrrpgce mailing list
>>>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>>>>> amster.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Ohrrpgce mailing list
>>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>>>> amster.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Ohrrpgce mailing list
>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>>> amster.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ohrrpgce mailing list
>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>> amster.org
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ohrrpgce mailing list
>>>>> ohrrpgce at lists.motherhamster.org
>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Ohrrpgce mailing list
>>>> ohrrpgce at lists.motherhamster.org
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>>>
>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
>>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170718/2ba2b12a/attachment.html>