NS8 apps naming convention

Community
, ,
1

Hi,

I wanted to pick your brain on the NS8 naming convention in search for consistency and clarity.

Community apps are now being made available/announced in various stages of maturity, that can range from a simple test to full production quality and everyting in between. So we have a development maturity and a release maturity, two different things.

As for apps that have been certified by the certification process, these will be released as ‘Production’ quality and be placed in the NethForge repo. For all other prohects/apps/initiatives, we need to settle on a justifying development maturity naming convention.

We see different dev maturity ‘labels’ such as “test”, “Pre-release”, "Alpha, “Beta”, “Test-release” etc. This maybe confusing to get a solid and consistent understanding of the ‘readiness’ or assistance an app development cycle or release needs.

Obviously number versioning as in “Alpha 1” and Alpha 2" needs to be taken into account.

What would you suggest to have as a consistent and clear development naming convention for apps that would eventually reach an end stage as “Production” in NethForge.?

TIA!

2

We Adopted the following Conventions in our release cycle naming scheme.

Alpha -
this is for apps that can at least install, configure, and be accessible via the web UI.

we then use alpha.1, alpha.2 etc, depending on additional fixes and additions that we might have.

Beta -
this is reserved for apps, that all issues identified by dev have been fixed.
We can backup and restore, clone, etc.
for other apps, this is where we might impelment SSO, Ldap or other variations.
if all works, we go to the next stage

Release Candidate(RC)
At this juncture, we have veirifed, Updates and Upgrades between versions can be handled effectively, without losing data, or causing issues to the server. At this point.

Production / Release
this does only have the version number, without anything else

Some apps are very simple, and may go from Alpha to RC then release.
while others may have very many alpha release cycles

When we are at a certain version, and there is something we are testing, or assessing whether to implement or not, you will usually see naming convection in the format

alpha-dev
beta-dev
etc,
We in no way intend those version for anyone to install or try. at times they are not released, but just available in a separate branch.

Once an app has been released, and has reached production status, we shift to using
dev or dev-testing release

Apps on our repo, without a release, are in no way intended for non dev installation, and may cause issues. Some of the issues include, not being able to remove or uninstall the app from the server.

3

Bump

(also see this thread)

4

I apologize for my late reply. I believe I expressed my thoughts in this discussion.

In summary:

  • Use Semver tags for the normal release cycle, e.g., 1.0.0, 1.1.0-dev.1, 1.1.0, etc.
  • Use application name suffixes to mark pre-stable releases within a repository, e.g., “Superapp (Beta).”
5

Here is a radical idea, can a community Software Center be created? (App Store)

Just like the Apple, Google and MS have to open up their tightly closed eco system of apps, services and more. Just like telecom providers have to open up their closed cabling infra to other vendors.

That way each entity can take responsibility over their own portfolio offerings, and limit liability and can have denyability over ‘other’ software centers/app store.

6

I think so far that that is a huge ask,

Equally, the support for third party repos allow for this that level of responsibility.

Implementing an entirely custom Software Center, Maybe through a fork, Which i dont think would be great for the community

1 Like