We could take it a step further like libreoffice do and require approvals
before committing the fixes etc.
On Mon, Mar 24, 2014 at 10:29 AM, Raine M. Ekman <[email protected]> wrote:
>
> There's the critical issue of mixing top and bottom posting. That
> really needs to be stamped out... please, stick to the style of the
> previous message and don't make it harder to read for the rest of us. :)
>
> As for branches, branching 1.0 off of master and only applying bug
> fixes to it or something like that sounds like a sound strategy to me,
> too.
>
> Citerar Jonathan Aquilina <[email protected]>:
>
> > I agree with you vesa, the master branch is the bleeding edge stuff. The
> > 1.0 branch would be for bug fix releases etc and overall Code
> improvements
> > in the sense of performance etc
> >
> >
> > On Sun, Mar 23, 2014 at 5:58 PM, Vesa <[email protected]> wrote:
> >
> >> On 03/23/2014 05:57 PM, Tobias Doerffel wrote:
> >> > Hi,
> >> >
> >> > as announced for weeks, we want to release 1.0.0 - if possible, today.
> >> > Is there any critical issue that I'm not aware of which should be
> >> > fixed before 1.0.0? As for the 1.0.0 milestone on Github, I'll ignore
> >> > the rather minor VST issue as the solution won't be a small fix only
> >> > but a rework of how the VST GUI/editor is instantiated and displayed.
> >> >
> >>
> >> IMO we should just release it. Doesn't matter if there are issues, it's
> >> already miles better than 0.4.15, and if something comes up, we can
> >> always release bugfix releases later. Doesn't matter if some small
> >> issues are unsolved now - it's better to just get the product out before
> >> people lose interest...
> >>
> >> Speaking of bugfixes, I wonder if we could discuss again about maybe
> >> dividing the development into two branches - stable and development? If
> >> I remember correctly, you said before that you prefer having just one
> >> master branch and each "subproject" in its own branch... but if we're
> >> going to release more often, I think we could benefit from a model of
> >> two separate branches - one that stays relatively stable and only gets
> >> bugfixes merged, and another where we'd be free to merge things more
> >> liberally, without worrying about whether they can be stabilized in
> time...
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Learn Graph Databases - Download FREE O'Reilly Book
> >> "Graph Databases" is the definitive new guide to graph databases and
> their
> >> applications. Written by three acclaimed leaders in the field,
> >> this first edition is now available. Download your free book today!
> >> http://p.sf.net/sfu/13534_NeoTech
> >> _______________________________________________
> >> LMMS-devel mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/lmms-devel
> >>
> >
> >
> >
> > --
> > Jonathan Aquilina
> >
>
>
>
> --
> [email protected]
> softrabbit on #lmms
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> LMMS-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/lmms-devel
>
--
Jonathan Aquilina
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
LMMS-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmms-devel
