.lvib / .llb / .lvilp Which one to choose and how to organize it?

[wiebe@CARYA]

---

@VinnyAstro wrote:
 So my question is, would you do revision history only on the code or also on any build you produce and send over?

---

You shouldn't commit compiled code. Keep copies somewhere where it's back upped regularly. 

You should make sure the committed code can reproduce the compiled code (of any version you delivered).

[VinnyAstro]

---

@crossrulz wrote:

---

SVN should be used to keep your source code.  Your customer should have no access to your repository.  You email, copy to a CD, etc. to give your customer the PPL.

---

Yep that wasn't part of my plans 🙂

Ok so I will eventually need to "save for previous version" before compiling then.

[VinnyAstro]

---

wiebe@CARYA wrote: Major would need a complete rework on their side.

Minor would add new features, maybe small changes to their side.

Revision should be compatible, but would fix bugs.

You can also use build. It's not in the installer though, that only has major, minor, revision...

It's not very critical (we actually use build for new features and bug fixes), but it helps if you stick to it.

The only thing that really matters is (back)traceability. You should know what commit was used for a version, and how to get from a version to a commit. This is pretty straightforward if you label each delivered version in SCC. We also tag each release. This makes it even easier to find. In HG this might get uncomfortable, AFAIK each tag is a copy of the entire repo. In SVN or GIT a tag is simply a reference to a place in time in the repo.

Okay, good to know, I'll try implementing something like this.

---

wiebe@CARYA wrote:

I'd go straight to GIT. GIT is almost like all good things from HG (local repo) and SVN (centralized repo) in one. You can commit even when you're not connected, something that is a big problem with SVN. 

---

Some colleagues do use Git as well and they starting to have a whole structure. But I think the problem is that they still first pass by an internal server that has a virtual machine running on Linux before any push is done on the git server. And I'm unsure how this would be dealt with LV...

I understand the offline argument, but that is not something I would really be troubled with I think. The advantage of SVN right now is its fairly simple usage but also that I have all the architecture ready for it atm (while we would surely have to do some changes on our servers to adapt it for LV.

[VinnyAstro]

---

wiebe@CARYA wrote:

---

@VinnyAstro wrote:
 So my question is, would you do revision history only on the code or also on any build you produce and send over?

---

You shouldn't commit compiled code. Keep copies somewhere where it's back upped regularly. 

You should make sure the committed code can reproduce the compiled code (of any version you delivered).

---

Yes that is exactly my point, if the compiled code doesn't execute as wanted, then you just delete it, make changes, commit, and match the version while recompiling?  

[cbutcher]

---

@VinnyAstro wrote:

---

@crossrulz wrote:

---

SVN should be used to keep your source code.  Your customer should have no access to your repository.  You email, copy to a CD, etc. to give your customer the PPL.

---

Yep that wasn't part of my plans 🙂

Ok so I will eventually need to "save for previous version" before compiling then.

---

Just in case you didn't realise (sorry if you got this already), if you're using say 2019 for development and you have for previous to 2011 (assuming it saves correctly and you didn't use any newer features), if you then compile a PPL from that code using 2019, it will still require 2019(+, if you enable the checkbox mentioned previously, which you usually want to do).

To produce built artifacts compatible with e.g. LabVIEW 2011 or the 2011 runtime, you need to install 2011 and use it to build the code (although you can if you want use 2019 to develop and save for previous as you said).

[wiebe@CARYA]

---

@VinnyAstro wrote:

---

wiebe@CARYA wrote:

---

@VinnyAstro wrote:
 So my question is, would you do revision history only on the code or also on any build you produce and send over?

---

You shouldn't commit compiled code. Keep copies somewhere where it's back upped regularly. 

You should make sure the committed code can reproduce the compiled code (of any version you delivered).

---

Yes that is exactly my point, if the compiled code doesn't execute as wanted, then you just delete it, make changes, commit, and match the version while recompiling?  

---

It's not that simple. It's quite simple in practice though. 

If the compiled code doesn't execute as wanted:

• The buggy build will be stored for reference. SC in SCC, exe in backup... This is a no-op.
• Revert to the version that was buggy for bug fixing a previous feature release (create a branch) or simply push the newest version to the customer.
• Make changes to the source code.
• Increase the version number.
• Compile.
• Save all. Optionally, close LV and reload. Save all *
• Commit the source code, backup the executable.
• Tag the version.
• Make the changes to the trunk (if it was a branch). Commit it.

You can have all sorts of situations. Sometimes you have customers that want a fix on an old release. Because the new release isn't tested (by them), or even because they didn't pay for the new features. That's when you make a branch...

Of course version numbering can get creative. If you have version 1.1.1 and 1.1.2, and you want to patch 1.1.1, how do you version it? 1.1.2 is already taken... You'll have to 1) anticipate on how likely this is to happen and 2) simply take shortcuts if it does happen (name it 1.1.3). As long as it's traceable, it's OK. Not nice, but OK... 

* Sometimes there are changes LV didn't save on "save all". It's not a big problem, but if you ever check out an old version (or revert to previous) you'll get changed VIs directly after you open the code. That's a bit scary.

[VinnyAstro]

---

@cbutcher wrote: Just in case you didn't realise (sorry if you got this already), if you're using say 2019 for development and you have for previous to 2011 (assuming it saves correctly and you didn't use any newer features), if you then compile a PPL from that code using 2019, it will still require 2019(+, if you enable the checkbox mentioned previously, which you usually want to do).

To produce built artifacts compatible with e.g. LabVIEW 2011 or the 2011 runtime, you need to install 2011 and use it to build the code (although you can if you want use 2019 to develop and save for previous as you said).

---

Hmmm I didn't know that nope. that is actually a big issue as I only have 2019 and I don't belive my company will be keen in buying other licenses for multiple versions ...

[VinnyAstro]

---

wiebe@CARYA wrote: It's not that simple. It's quite simple in practice though. 

If the compiled code doesn't execute as wanted:

• The buggy build will be stored for reference. SC in SCC, exe in backup... This is a no-op.
• Revert to the version that was buggy for bug fixing a previous feature release (create a branch) or simply push the newest version to the customer.
• Make changes to the source code.
• Increase the version number.
• Compile.
• Save all. Optionally, close LV and reload. Save all *
• Commit the source code, backup the executable.
• Tag the version.
• Make the changes to the trunk (if it was a branch). Commit it.

You can have all sorts of situations. Sometimes you have customers that want a fix on an old release. Because the new release isn't tested (by them), or even because they didn't pay for the new features. That's when you make a branch...

Of course version numbering can get creative. If you have version 1.1.1 and 1.1.2, and you want to patch 1.1.1, how do you version it? 1.1.2 is already taken... You'll have to 1) anticipate on how likely this is to happen and 2) simply take shortcuts if it does happen (name it 1.1.3). As long as it's traceable, it's OK. Not nice, but OK... 

* Sometimes there are changes LV didn't save on "save all". It's not a big problem, but if you ever check out an old version (or revert to previous) you'll get changed VIs directly after you open the code. That's a bit scary.

---

Indeed, it's not that simple ^^

I'll start small and see how things are growing I think, thanks for your input. 🙂

[wiebe@CARYA]

---

@VinnyAstro wrote:

---

wiebe@CARYA wrote: It's not that simple. It's quite simple in practice though. 

If the compiled code doesn't execute as wanted:

• The buggy build will be stored for reference. SC in SCC, exe in backup... This is a no-op.
• Revert to the version that was buggy for bug fixing a previous feature release (create a branch) or simply push the newest version to the customer.
• Make changes to the source code.
• Increase the version number.
• Compile.
• Save all. Optionally, close LV and reload. Save all *
• Commit the source code, backup the executable.
• Tag the version.
• Make the changes to the trunk (if it was a branch). Commit it.

You can have all sorts of situations. Sometimes you have customers that want a fix on an old release. Because the new release isn't tested (by them), or even because they didn't pay for the new features. That's when you make a branch...

Of course version numbering can get creative. If you have version 1.1.1 and 1.1.2, and you want to patch 1.1.1, how do you version it? 1.1.2 is already taken... You'll have to 1) anticipate on how likely this is to happen and 2) simply take shortcuts if it does happen (name it 1.1.3). As long as it's traceable, it's OK. Not nice, but OK... 

* Sometimes there are changes LV didn't save on "save all". It's not a big problem, but if you ever check out an old version (or revert to previous) you'll get changed VIs directly after you open the code. That's a bit scary.

---

Indeed, it's not that simple ^^

I'll start small and see how things are growing I think, thanks for your input. 🙂

---

Still so much easier than doing it without SCC 😁...

[cbutcher]

---

@VinnyAstro wrote:

Hmmm I didn't know that nope. that is actually a big issue as I only have 2019 and I don't belive my company will be keen in buying other licenses for multiple versions ...

---

The runtime is free, so if you can produce tools for your clients using 2019, you're ok. 

This doesn't work for SubVIs, which is probably the easiest way for me, as your hypothetical stand-in client, to use code you write - but you could use e.g. a local TCP connection to communicate between executables.

If instead you can directly provide an exe, then there's no problem - but it sounded like you're supposed to provide libraries and tools more than applications, which makes this problematic.

Can you persuade your client(s) to upgrade if you can't persuade your boss(es) to buy older licenses? There have been lots of improvements in recent versions...