Should application directory names include version numbers? [closed]
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I have an application which is expected to have occasional updates. For my sins, its a .Net Core app running on Centos as a systemd service. The service is expected be available running more or less 24/7 for long periods (months/years).
I need to update it remotely. I actually have a mechanism - it downloads an RPM when available, spawns a shell, and starts a nohup background bash script including yum -y localinstall <rpm name>
, then exits. The bash script's rpm spec file unpacks into a new directory /usr/bin/appname-<version number>
, and on completion moves a symlink /usr/bin/appname
to point to the new directory. A systemctl restart <appname>
completes the process, and the directory is otherwise referenced through the symlink.
So if the app is 'foo', I have /usr/bin/foo_1.2.3.4
, with the symlink /usr/bin/foo
pointing to it.
This actually works quite well. However, management are unhappy with the versioned directory scheme. I've been asked to check if this is considered acceptable practice. If not, what is standard practice? In theory, I could shut down the service, write everything into /usr/bin/appname
(not a symlink), and then start it up again from the bash script, but I'm trying not to have a directory containing files of different versions at the same time.
linux directory-structure version standard rpm-spec
closed as primarily opinion-based by roaima, Jeff Schaller, Thomas Dickey, RalfFriedl, Archemar Sep 11 at 7:13
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |Â
up vote
1
down vote
favorite
I have an application which is expected to have occasional updates. For my sins, its a .Net Core app running on Centos as a systemd service. The service is expected be available running more or less 24/7 for long periods (months/years).
I need to update it remotely. I actually have a mechanism - it downloads an RPM when available, spawns a shell, and starts a nohup background bash script including yum -y localinstall <rpm name>
, then exits. The bash script's rpm spec file unpacks into a new directory /usr/bin/appname-<version number>
, and on completion moves a symlink /usr/bin/appname
to point to the new directory. A systemctl restart <appname>
completes the process, and the directory is otherwise referenced through the symlink.
So if the app is 'foo', I have /usr/bin/foo_1.2.3.4
, with the symlink /usr/bin/foo
pointing to it.
This actually works quite well. However, management are unhappy with the versioned directory scheme. I've been asked to check if this is considered acceptable practice. If not, what is standard practice? In theory, I could shut down the service, write everything into /usr/bin/appname
(not a symlink), and then start it up again from the bash script, but I'm trying not to have a directory containing files of different versions at the same time.
linux directory-structure version standard rpm-spec
closed as primarily opinion-based by roaima, Jeff Schaller, Thomas Dickey, RalfFriedl, Archemar Sep 11 at 7:13
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
I use versioned directory names, with a symlink holding the generic name. This sounds exactly the same as your solution. I find it works really well because I can usually rollback instantly if I need to. Also I can afford to take time to apply an upgrade, leaving it partially built overnight if it's a particularly complex process.
â roaima
Sep 10 at 22:14
Don't know about standard but this fairly common... Simple yet flexible. To be honest I don't understand why does your management complain - what's their proposed solution? :)
â pi0tr
Sep 10 at 22:14
The crux of the matter is really whether there's any (internal) justification for "management are unhappy with the versioned directory scheme". You don't necessarily need to share it here, but you need to work out whether or not there is an underlying reason for this unhappiness (other than "I didn't think of that").
â roaima
Sep 10 at 22:15
Important chunks of your Q vanished because you used anglebrackets in Stack text where they are treated as unallowed HTML and suppressed; I submitted an edit to markdown as 'code' which doesn't have this problem and is more appropriate anyway for commandlines and pathnames.
â dave_thompson_085
Sep 11 at 3:27
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I have an application which is expected to have occasional updates. For my sins, its a .Net Core app running on Centos as a systemd service. The service is expected be available running more or less 24/7 for long periods (months/years).
I need to update it remotely. I actually have a mechanism - it downloads an RPM when available, spawns a shell, and starts a nohup background bash script including yum -y localinstall <rpm name>
, then exits. The bash script's rpm spec file unpacks into a new directory /usr/bin/appname-<version number>
, and on completion moves a symlink /usr/bin/appname
to point to the new directory. A systemctl restart <appname>
completes the process, and the directory is otherwise referenced through the symlink.
So if the app is 'foo', I have /usr/bin/foo_1.2.3.4
, with the symlink /usr/bin/foo
pointing to it.
This actually works quite well. However, management are unhappy with the versioned directory scheme. I've been asked to check if this is considered acceptable practice. If not, what is standard practice? In theory, I could shut down the service, write everything into /usr/bin/appname
(not a symlink), and then start it up again from the bash script, but I'm trying not to have a directory containing files of different versions at the same time.
linux directory-structure version standard rpm-spec
I have an application which is expected to have occasional updates. For my sins, its a .Net Core app running on Centos as a systemd service. The service is expected be available running more or less 24/7 for long periods (months/years).
I need to update it remotely. I actually have a mechanism - it downloads an RPM when available, spawns a shell, and starts a nohup background bash script including yum -y localinstall <rpm name>
, then exits. The bash script's rpm spec file unpacks into a new directory /usr/bin/appname-<version number>
, and on completion moves a symlink /usr/bin/appname
to point to the new directory. A systemctl restart <appname>
completes the process, and the directory is otherwise referenced through the symlink.
So if the app is 'foo', I have /usr/bin/foo_1.2.3.4
, with the symlink /usr/bin/foo
pointing to it.
This actually works quite well. However, management are unhappy with the versioned directory scheme. I've been asked to check if this is considered acceptable practice. If not, what is standard practice? In theory, I could shut down the service, write everything into /usr/bin/appname
(not a symlink), and then start it up again from the bash script, but I'm trying not to have a directory containing files of different versions at the same time.
linux directory-structure version standard rpm-spec
linux directory-structure version standard rpm-spec
edited Sep 11 at 7:14
dave_thompson_085
2,0071810
2,0071810
asked Sep 10 at 22:01
user3587642
61
61
closed as primarily opinion-based by roaima, Jeff Schaller, Thomas Dickey, RalfFriedl, Archemar Sep 11 at 7:13
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as primarily opinion-based by roaima, Jeff Schaller, Thomas Dickey, RalfFriedl, Archemar Sep 11 at 7:13
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
I use versioned directory names, with a symlink holding the generic name. This sounds exactly the same as your solution. I find it works really well because I can usually rollback instantly if I need to. Also I can afford to take time to apply an upgrade, leaving it partially built overnight if it's a particularly complex process.
â roaima
Sep 10 at 22:14
Don't know about standard but this fairly common... Simple yet flexible. To be honest I don't understand why does your management complain - what's their proposed solution? :)
â pi0tr
Sep 10 at 22:14
The crux of the matter is really whether there's any (internal) justification for "management are unhappy with the versioned directory scheme". You don't necessarily need to share it here, but you need to work out whether or not there is an underlying reason for this unhappiness (other than "I didn't think of that").
â roaima
Sep 10 at 22:15
Important chunks of your Q vanished because you used anglebrackets in Stack text where they are treated as unallowed HTML and suppressed; I submitted an edit to markdown as 'code' which doesn't have this problem and is more appropriate anyway for commandlines and pathnames.
â dave_thompson_085
Sep 11 at 3:27
add a comment |Â
I use versioned directory names, with a symlink holding the generic name. This sounds exactly the same as your solution. I find it works really well because I can usually rollback instantly if I need to. Also I can afford to take time to apply an upgrade, leaving it partially built overnight if it's a particularly complex process.
â roaima
Sep 10 at 22:14
Don't know about standard but this fairly common... Simple yet flexible. To be honest I don't understand why does your management complain - what's their proposed solution? :)
â pi0tr
Sep 10 at 22:14
The crux of the matter is really whether there's any (internal) justification for "management are unhappy with the versioned directory scheme". You don't necessarily need to share it here, but you need to work out whether or not there is an underlying reason for this unhappiness (other than "I didn't think of that").
â roaima
Sep 10 at 22:15
Important chunks of your Q vanished because you used anglebrackets in Stack text where they are treated as unallowed HTML and suppressed; I submitted an edit to markdown as 'code' which doesn't have this problem and is more appropriate anyway for commandlines and pathnames.
â dave_thompson_085
Sep 11 at 3:27
I use versioned directory names, with a symlink holding the generic name. This sounds exactly the same as your solution. I find it works really well because I can usually rollback instantly if I need to. Also I can afford to take time to apply an upgrade, leaving it partially built overnight if it's a particularly complex process.
â roaima
Sep 10 at 22:14
I use versioned directory names, with a symlink holding the generic name. This sounds exactly the same as your solution. I find it works really well because I can usually rollback instantly if I need to. Also I can afford to take time to apply an upgrade, leaving it partially built overnight if it's a particularly complex process.
â roaima
Sep 10 at 22:14
Don't know about standard but this fairly common... Simple yet flexible. To be honest I don't understand why does your management complain - what's their proposed solution? :)
â pi0tr
Sep 10 at 22:14
Don't know about standard but this fairly common... Simple yet flexible. To be honest I don't understand why does your management complain - what's their proposed solution? :)
â pi0tr
Sep 10 at 22:14
The crux of the matter is really whether there's any (internal) justification for "management are unhappy with the versioned directory scheme". You don't necessarily need to share it here, but you need to work out whether or not there is an underlying reason for this unhappiness (other than "I didn't think of that").
â roaima
Sep 10 at 22:15
The crux of the matter is really whether there's any (internal) justification for "management are unhappy with the versioned directory scheme". You don't necessarily need to share it here, but you need to work out whether or not there is an underlying reason for this unhappiness (other than "I didn't think of that").
â roaima
Sep 10 at 22:15
Important chunks of your Q vanished because you used anglebrackets in Stack text where they are treated as unallowed HTML and suppressed; I submitted an edit to markdown as 'code' which doesn't have this problem and is more appropriate anyway for commandlines and pathnames.
â dave_thompson_085
Sep 11 at 3:27
Important chunks of your Q vanished because you used anglebrackets in Stack text where they are treated as unallowed HTML and suppressed; I submitted an edit to markdown as 'code' which doesn't have this problem and is more appropriate anyway for commandlines and pathnames.
â dave_thompson_085
Sep 11 at 3:27
add a comment |Â
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
I use versioned directory names, with a symlink holding the generic name. This sounds exactly the same as your solution. I find it works really well because I can usually rollback instantly if I need to. Also I can afford to take time to apply an upgrade, leaving it partially built overnight if it's a particularly complex process.
â roaima
Sep 10 at 22:14
Don't know about standard but this fairly common... Simple yet flexible. To be honest I don't understand why does your management complain - what's their proposed solution? :)
â pi0tr
Sep 10 at 22:14
The crux of the matter is really whether there's any (internal) justification for "management are unhappy with the versioned directory scheme". You don't necessarily need to share it here, but you need to work out whether or not there is an underlying reason for this unhappiness (other than "I didn't think of that").
â roaima
Sep 10 at 22:15
Important chunks of your Q vanished because you used anglebrackets in Stack text where they are treated as unallowed HTML and suppressed; I submitted an edit to markdown as 'code' which doesn't have this problem and is more appropriate anyway for commandlines and pathnames.
â dave_thompson_085
Sep 11 at 3:27