Karl:

You're probably right on the 3 types. However, the statement:

You want to make changes to the software? Then you are a software developer, and version control is part of that.

needs a little wiggle room. If someone just wants to add a splash screen with their call, that's a change, but I don't think they need version control to do it. The problem is implementation: at what point do you transition from casual programmer to software developer? I think there are a lot of "add-a-splash-screen" programmers who are sticking their toes into the programming ocean for the first time. I think that's great...it's a fun element of our hobby! Of course, the danger is that wigglie toes in an ocean can attract attention from some mean-spirited creatures and some cautions need to then be put in place to safeguard the code. I just don't know where that line is drawn.

For me, when I'm finished working for the day, I always make a back a copy of the current files into a Backup directory. Using my earlier example, I would have:

?? C://IanLee/Version106/ubix_20.ino...

????????????? /Version1072/ubix_20.ino
????????????? /WorkingVersion/ubix_20/ubix_20.ino...

????????????? /Backup/WorkingVersion/ubix_20/ubitx_20.ino? // and the rest of the files

Notice how Backup is really a mirror of the WorkingVersion directory. As long as I back up at the end of each day, my worst case is I lose one day's work. I'm not as religious about this as I should be, which a real VC would enforce, but it works for me now.

In the end, it's up to the user to decide what's needed. The true value of VC only comes clearly into focus when something really bad happens and six months worth of work disappears.

Jack, W8TEE

On Tuesday, April 24, 2018, 8:59:11 AM EDT, Karl Heinz Kremer, K5KHK <khk@...> wrote:

Jack,?

I think we are dealign with three types of users:

1) The "Give me a simple way to flash uBitx, and I don't care about version numbers, I don't care about changes, I just want to use?the latest and greatest features" user. For?them, a version number is not important,?because they very likely don't even want to keep more than one version around. They would very likely be happy with just using avrdude and flashing a hex file, which Ian provides.?

2) The "I want to experiment with the software and make my own changes, but always want a save way to get back to a working configuration" type of user. For them, just like learning?the syntax of C/C++ and how the library system in the Arduino IDE works, it may be a good idea to get a basic understanding of a version control system and use that to keep track of changes.?You want to make changes to the software? Then you are a software developer, and version control is part of that.?

3) The "I want to have access to different versions, but don't?want to learn how software development actually works" type. For them, your approach may be a good way to keep track of different versions. ?

Especially if you fall into #2, and you want to make changes, you need a way to figure out what you've changed. When you hack away on a keyboard, mistakes happen and you may not even remember touching a file. A version control system always will tell you exactly what has changed, and then you can figure out how to get back to a working system. So, in m opinion if you?want to make changes, you either need to be very good with the Unix diff command, or have a VC system?that takes care of that for you.?

--
Karl Heinz - K5KHK

For me, when I'm finished working for the day, I always make a back a copy of the current files into a Backup directory.

On April 24, 2018 at 11:26 AM "Jerry Gaffke via Groups.Io" <jgaffke@...> wrote:

A tool like git is great if you have a bunch of programmers collaborating on a project.
Especially if they all understand how to use git.
Here's a tutorial on git, there's a tool tip when mouse hovering over the cartoon.
? ??
The diff command is much easier to master than git.

I don't have much use for git or cvs or whatever when working on small home projects.
I just copy my work into sequentially numbered *.txt files or zip archives, which are ignored by the Arduino IDE
For example, at the command line under linux:? ?
? ? cd ~/blinky
? ? zip blinky43.zip *.ino *.c *.h

And if I really cared about my blinky project, I'd occasionally copy that out to a USB stick.
Or onto a 9 track 1600 bpi tape.

I've been doing it this way since long before cvs or git was created.
Though I did switch from tar to zip when forced to work under MSDOS in the 1980's.

I usually have a revision history at the top of the main file in the project so I know where stuff changes.?
Here's how it's done under git:??

Jerry, KE7ER



On Tue, Apr 24, 2018 at 07:37 am, Jack Purdum wrote:

For me, when I'm finished working for the day, I always make a back a copy of the current files into a Backup directory.

All the world is a market.

Meet the needs of your customers and your move a lot of product.

Try to tell your customers “what they need to do, “ and they may find another vendor.

Trick here is to figure out how to make it easy on multiple types of customers.

that might require you storing your files 2 different ways, but that’s extra work for only ONE person, and benefits tens to hundreds to thousands.

On Apr 24, 2018, at 10:37, Jack Purdum via Groups.Io <jjpurdum@...> wrote:

Karl:

You're probably right on the 3 types. However, the statement:

You want to make changes to the software? Then you are a software developer, and version control is part of that.

needs a little wiggle room. If someone just wants to add a splash screen with their call, that's a change, but I don't think they need version control to do it. The problem is implementation: at what point do you transition from casual programmer to software developer? I think there are a lot of "add-a-splash-screen" programmers who are sticking their toes into the programming ocean for the first time. I think that's great...it's a fun element of our hobby! Of course, the danger is that wigglie toes in an ocean can attract attention from some mean-spirited creatures and some cautions need to then be put in place to safeguard the code. I just don't know where that line is drawn.

For me, when I'm finished working for the day, I always make a back a copy of the current files into a Backup directory. Using my earlier example, I would have:

?? C://IanLee/Version106/ubix_20.ino...

????????????? /Version1072/ubix_20.ino
????????????? /WorkingVersion/ubix_20/ubix_20.ino...

????????????? /Backup/WorkingVersion/ubix_20/ubitx_20.ino? // and the rest of the files

Notice how Backup is really a mirror of the WorkingVersion directory. As long as I back up at the end of each day, my worst case is I lose one day's work. I'm not as religious about this as I should be, which a real VC would enforce, but it works for me now.

In the end, it's up to the user to decide what's needed. The true value of VC only comes clearly into focus when something really bad happens and six months worth of work disappears.

Jack, W8TEE

On Tuesday, April 24, 2018, 8:59:11 AM EDT, Karl Heinz Kremer, K5KHK <khk@...> wrote:

Jack,?

I think we are dealign with three types of users:

1) The "Give me a simple way to flash uBitx, and I don't care about version numbers, I don't care about changes, I just want to use?the latest and greatest features" user. For?them, a version number is not important,?because they very likely don't even want to keep more than one version around. They would very likely be happy with just using avrdude and flashing a hex file, which Ian provides.?

2) The "I want to experiment with the software and make my own changes, but always want a save way to get back to a working configuration" type of user. For them, just like learning?the syntax of C/C++ and how the library system in the Arduino IDE works, it may be a good idea to get a basic understanding of a version control system and use that to keep track of changes.?You want to make changes to the software? Then you are a software developer, and version control is part of that.?

3) The "I want to have access to different versions, but don't?want to learn how software development actually works" type. For them, your approach may be a good way to keep track of different versions. ?

Especially if you fall into #2, and you want to make changes, you need a way to figure out what you've changed. When you hack away on a keyboard, mistakes happen and you may not even remember touching a file. A version control system always will tell you exactly what has changed, and then you can figure out how to get back to a working system. So, in m opinion if you?want to make changes, you either need to be very good with the Unix diff command, or have a VC system?that takes care of that for you.?

--
Karl Heinz - K5KHK

?Hi All,

The latest KD8CEC firmware manual (1.073) gives? click-by-click
instructions for downloading from github.

You do not have to know a thing about github to use it; just follow the steps.

Many thanks to Jon,KK6VLO for contributing text and graphics to that
section of the manual.

Go to , Mike ZL1AXGs excellent website to get the manual.

Rod KM6SN

On 04/24/2018 07:56 AM, Gordon Gibby wrote:

All the world is a market.

Meet the needs of your customers and your move a lot of product.

Try to tell your customers “what they need to do, “ and they may find another vendor.

Trick here is to figure out how to make it easy on multiple types of customers.

that might require you storing your files 2 different ways, but that’s extra work for only ONE person, and benefits tens to hundreds to thousands.

On Apr 24, 2018, at 10:37, Jack Purdum via Groups.Io <jjpurdum@...> wrote:

Karl:

You're probably right on the 3 types. However, the statement:

You want to make changes to the software? Then you are a software developer, and version control is part of that.

needs a little wiggle room. If someone just wants to add a splash screen with their call, that's a change, but I don't think they need version control to do it. The problem is implementation: at what point do you transition from casual programmer to software developer? I think there are a lot of "add-a-splash-screen" programmers who are sticking their toes into the programming ocean for the first time. I think that's great...it's a fun element of our hobby! Of course, the danger is that wigglie toes in an ocean can attract attention from some mean-spirited creatures and some cautions need to then be put in place to safeguard the code. I just don't know where that line is drawn.

For me, when I'm finished working for the day, I always make a back a copy of the current files into a Backup directory. Using my earlier example, I would have:

?? C://IanLee/Version106/ubix_20.ino...

????????????? /Version1072/ubix_20.ino
????????????? /WorkingVersion/ubix_20/ubix_20.ino...

????????????? /Backup/WorkingVersion/ubix_20/ubitx_20.ino? // and the rest of the files

Notice how Backup is really a mirror of the WorkingVersion directory. As long as I back up at the end of each day, my worst case is I lose one day's work. I'm not as religious about this as I should be, which a real VC would enforce, but it works for me now.

In the end, it's up to the user to decide what's needed. The true value of VC only comes clearly into focus when something really bad happens and six months worth of work disappears.

Jack, W8TEE

On Tuesday, April 24, 2018, 8:59:11 AM EDT, Karl Heinz Kremer, K5KHK <khk@...> wrote:

Jack,?

I think we are dealign with three types of users:

1) The "Give me a simple way to flash uBitx, and I don't care about version numbers, I don't care about changes, I just want to use?the latest and greatest features" user. For?them, a version number is not important,?because they very likely don't even want to keep more than one version around. They would very likely be happy with just using avrdude and flashing a hex file, which Ian provides.?

2) The "I want to experiment with the software and make my own changes, but always want a save way to get back to a working configuration" type of user. For them, just like learning?the syntax of C/C++ and how the library system in the Arduino IDE works, it may be a good idea to get a basic understanding of a version control system and use that to keep track of changes.?You want to make changes to the software? Then you are a software developer, and version control is part of that.?

3) The "I want to have access to different versions, but don't?want to learn how software development actually works" type. For them, your approach may be a good way to keep track of different versions. ?

Especially if you fall into #2, and you want to make changes, you need a way to figure out what you've changed. When you hack away on a keyboard, mistakes happen and you may not even remember touching a file. A version control system always will tell you exactly what has changed, and then you can figure out how to get back to a working system. So, in m opinion if you?want to make changes, you either need to be very good with the Unix diff command, or have a VC system?that takes care of that for you.?

--
Karl Heinz - K5KHK

It would also make it easier to identify the version just by a glance at the directory that hold the code files. Because the INO file must have the same name as the directory its in for the IDE to compile the file, instead of all versions sitting in a directory name ubitx_20, it makes sense to have:

C://ubitx_20V1072/ubitx_20V1072.ino

????????????????? ubitx_factory_alignment.cpp

????????????????? //...and so on...
????????????????????????????

This way the "old" versions are preserved when the new one is released.

I would still like to see only the source file containing the setup() and loop() functions be given the INO secondary file name and all the others given CPP secondary file names. Currently, using all INO file names causes the compiler to get sloppy on parameter type checking and that can be a nasty bug to isolate, especially when no symbolic debugger is available. True, the change will identify a host of warnings, but should uncover no bugs, since the code compiles correctly as is. I did that for Farhan's original code and while it took some time, it's really grunt work and not difficult to change.

Jack, W8TEE

On Monday, April 23, 2018, 11:45:03 PM EDT, K9HZ <bill@...> wrote:

Im not sure you understand this completely, so ill put this more clearly. When the main sketch has the same name from version to version and you upload it to the Arduino IDE, it over-writes the previous version because it has the SAME NAME. ?Of you were to include the version number in the program name, they would not over-write.?

Dr.?William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ

?

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

?

Owner – Operator

Villa Grand Piton - J68HZ

Soufriere, St. Lucia W.I.

Rent it:

email:??bill@...

?

On Apr 23, 2018, at 6:56 PM, Ian Lee <kd8cec@...> wrote:

William

I use git for version control, but it seems to be difficult to trace history when the file name changes.

Instead, I will create a separate file to keep track of which files have changed each time I deploy.

All filenames are now cleaned up.

Since Version 1.070, there was work such as splitting and merging files to support various hardware.

I will publish Version 1.073 (Beta) within a day.

Thank you for testing the firmware.

Ian KD8CEC

2018-04-24 9:31 GMT+09:00 K9HZ <bill@...>:

Ian... would you PLEASE consider writing the version number in the file name of the code?? That way different versions can be saved easily in the Arduino ISD.?

Dr.?William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ

?

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

?

Owner – Operator

Villa Grand Piton - J68HZ

Soufriere, St. Lucia W.I.

Rent it:

email:??bill@...

?

On Apr 22, 2018, at 2:50 PM, Ian Lee <kd8cec@...> wrote:

Rod, All

I am always thanking Rod.

And I'm sorry to interrupt Rod's work with too many changes in functionality.

1.072 will be tested and will be released as 1.073 Beta.

Several minor ones have been added.

Please wait for a day or two to download the code or firmware.?

Perhaps 1.07x will continue to be a Beta version.
Frequent formal firmware release seems to be inconvenient for some people, so I try to release it after various tests.

I think Version 1.061 is a stable version.?I know there is some nice firmware based on Version 1.061 and I will install it on my Spare uBITX.

Version 1.061 and later versions are also based on Version 1.061.

The Portable version and the various language versions are all excellent Firmware and I share code with them.

Please wait for a day or two?, I'll release version 1.073 beta after testing in various environments (including Linux).

Thank you

Ian KD8CEC

2018-04-22 7:25 GMT+09:00 Rod Davis <km6sn@...>:

Hi All,

Ron, W7HD, points out that downloading the KD8CEC 1.072 can be a problem

because version 1.072 does not appear in the list.

It is necessary to click on the Branch button, then use your mouse wheel to

scroll down until the version1.072 is revealed.

Best to All,

Rod KM6SN

See below for an excerpt:

Download the CECFW source code from github

For this example we will be using version 1.072.

<Image4>

Click the “Branch” button to select version 1.072, then click “Clone or download” and click “Download ZIP”. Unzip the downloaded file and make a note of the folder location, or move the unzipped directory into your arduino sketch folder.

--
Best 73
KD8CEC / Ph.D ian lee
kd8cec@...
(my blog)

--
Best 73
KD8CEC / Ph.D ian lee
kd8cec@...
(my blog)

But if this doesn’t work for windows users, the most common sort of us I
suspect, exactly how does this benefit us?
The only Linux that I have available to me is a raspberry. I have plenty
of those. Am I able to run the integrated development environment on
raspberry?

On Apr 24, 2018, at 08:31, Gordon Gibby <ggibby@...
<mailto:ggibby@...>> wrote:

Hmmmmm. Interesting....


On Apr 24, 2018, at 08:24, Karl Heinz Kremer, K5KHK <khk@...
<mailto:khk@...>> wrote:

This is why Ian is using a version control system. As long as there
are labels attached to each version, you can always go back and
forward between versions without having to resort to different file
names or different folders. As Ian explained, using different
filenames actually breaks this mechanism. You may want to look into a
Git tutorial to see how easy it is to - with just three or four
commands you can do all that. All you need is to have Git installed
on your system.

To create a copy of the repository, you use this command (this
assumes a Linux or other Unix type system - I don't know what the
corresponding commands would be for Windows):

git clone
<>

You then go into the ubitx folder:

cd ubitx

From within this folder, you can list the tags that are available:

git tags

If you want to use the latest version, you are usually already all
set, to go back to a previous version, you would use the checkout
command:

git checkout v1.06

The argument you use (in this case "v1.06" is one of the tags that
were listed with the "tags" command above).

You can always find out what's going on by using the "status" command:

git status

Especially if you want to make your own changes, Git is a great
system, because you will always know what you've changed and you can
keep track of your changes by creating your own branches and tags.

This is how professional software development is done.

--
Karl Heinz - K5KHK