Navigator now supports converting controls to script-only stack behaviors

[Brian Milby]

The files on GitHub and your workstation should be pretty much the same.
Like Trevor was saying, you would have a develop branch that contained your
in progress code. The master branch would be the release. Every beta could
be a commit in the dev branch. When ready for a final release, the code is
merged up to master.
On Thu, Jan 25, 2018 at 1:54 PM Geoff Canyon via use-livecode <
use-livecode at lists.runrev.com> wrote:

> Any suggestions where to go to figure this out? At the most basic level,
> all I need is:
>
> 1. A "current released version" of Navigator on GitHub.
> 2. A work-in-progress version on my computer, in my LiveCode installation.
> 3. The ability to merge my copy into the GitHub version.
>
> And obviously, have multiple dev versions, release versions, etc., but for
> now I just need dev and release, and even that seems beyond the ability of
> any web page to explain simply. Nothing I've read seems to even come close
> to explaining how to do that. Or am I just completely misunderstanding how
> git works? Even basic tutorials seem to start with literally no description
> of what the actual workflow of git is, and simply dive into various git
> commands using undefined terminology. <grrr>
>
> On Thu, Jan 25, 2018 at 5:40 AM, Trevor DeVore via use-livecode <
> use-livecode at lists.runrev.com> wrote:
>
> > On Thu, Jan 25, 2018 at 3:36 AM Geoff Canyon via use-livecode <
> > use-livecode at lists.runrev.com> wrote:
> >
> > >
> > > I have a fix coded, but I'm in the middle of another update, so I will
> > > update the whole thing tomorrow morning. (This is the sort of thing
> > GitHub
> > > is supposed to be good for, right? Heh -- need to figure that out...)
> >
> >
> > A couple of quick tips. Some of the vocabulary may be new. Just google
> each
> > concept and you will find lots of info. Git is really confusing at first
> > and then one day it isn’t and you wonder how you ever lived without it.
> >
> > Look into branching. A simple approach for an individual is that your
> > master branch has the stable version of your app. You work on each
> feature
> > in a separate branch that you then merge into master when it is ready.
> >
> > Whenever you want to make a new public release of your app tag the commit
> > in master that has the release version. This allows you to easily check
> out
> > a branch with that exact version of your app if you need to in the
> future.
> >
> > If you want to keep your master branch clean when merging other branches
> in
> > (not too many commits) look into interactive rebasing. Interactive
> rebasing
> > can be used to squash a bunch of commits in a branch down to one (or
> more).
> > That way when you merge a feature branch into master it only appears as
> one
> > commit, even if you made 30 commits while working on the feature.
> >
> > Trevor DeVore
> > ScreenSteps
> >
> > >
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode