Hi,

I'm pretty happy with the rolling release model[1] from Manjaro and
Arch. I only install the system once and from there is just updating.
I'm using such model for Grafoscopio with pretty good results. There is
an update menu that takes care of all the updates and each 3 or 4 months
we make some Data Week local workshop+hackathon, where we make more
noise about the new features in Grafoscopio and provide help with clean
installs and use international events to increase awareness about what
we are doing. For example, we have a traditional Data Week that has the
last day overlapping with the Open Data Day celebration (see [4] for
details, in Spanish).

[1] https://en.wikipedia.org/wiki/Rolling_release
[2] https://manjaro.org/
[3] https://www.archlinux.org/
[4] https://is.gd/oddbog

So, I think that an update menu that uses pip (or conda-anaconda) to let
the users be one click away of the latest version of Leo is important,
taking advantage of having already Leo/Python installed and runnable.
Also, it's important to organize some kind of (distributed/local) event
with a party/celebration approach to let the newbies become part of the
community, hopefully overlapping with other wider events.

Cheers,

Offray
On 28/02/18 14:54, Viktor Ransmayr wrote:
> Hello Edward,
>
> 2018-02-28 17:05 GMT+01:00 Edward K. Ream <edream...@gmail.com
> <mailto:edream...@gmail.com>>:
>
>     On Wednesday, February 28, 2018 at 9:59:02 AM UTC-6, Edward K.
>     Ream wrote:
>
>         I am not satisfied with the profit/effort ratio. Here are
>         preliminary thoughts.
>
>
>     I would like to release "lite" versions of Leo every month or so. 
>     These would appear only on PyPI and github. Nothing on
>     sourceforge. No pyinstaller or other exe files.  No .zip folders.
>
>     Part of this idea is focusing on shorter-term milestones: 5.7.1,
>     5.7.2, etc.  And focusing on milestones rather than "grand"
>     official releases.
>
>
> I believe such a release process change would be an improvement for Leo!
>
> I would also consider a time-based instead of a feature-based release
> process as another option to discuss ...
>
> A good example, that I'm aware of, is the Mercurial-SCM Project.
>
> See [1] for a description of their release process.
>
> With kind regards,
>
> Viktor
>
> ---
>
> [1] Time-based Release Plan
>
> * https://www.mercurial-scm.org/wiki/TimeBasedReleasePlan
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to leo-editor+unsubscr...@googlegroups.com
> <mailto:leo-editor+unsubscr...@googlegroups.com>.
> To post to this group, send email to leo-editor@googlegroups.com
> <mailto:leo-editor@googlegroups.com>.
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Reply via email to