Each project is a web app, a subdomain of voyc.com, stored in gitlab (previously github).

layout - browser screen splitter

account - submodule, user management

fx - submodule, library of game effects

icon - submodule, library of icons

jslib - library of javascript tools

minimal - html, css, javascript for a minimal web app

homepage - homepage for voyc.com

pokerface - facial expressions of artificial feelings

geo - geopolitics map drawing

curriculum - voycipedia

global - previously voyc, before geo

samantha - AI webchat

classy - comment classifier

sandbox - experiment and demo

bahasa - language

flash - flash card memorization

guru - random quote

mai - language

plunder - game added atop voyc

sanskrit - language

robots - multiple hardware projects

vote - ranked choice voting

wordnet - database only, sql version of Princeton's WordNet

model - starter project template

timeline - timeline

voyc - leftover from when geo/global was voyc.com

projects checklist sheet

webapps sheet

robots.txt
.well-known/*
js.min
css.min
index.php

Most of our projects have a dev and a production version.
Example:

• jslib.voyc.com
• jslib.hagstrand.com

These two sites have duplicate content.
We want to tell the search engines to index prod, not dev.
How do we do that?

User-agent: *
Disallow: /

This prevents the search engines from crawling the site.
But it does NOT prevent the search engines from indexing the site.

<meta name='robots' content='noindex,follow' />

This means that prod and dev will have a different line in index.html.
How can I do this dynamically? The crawlers are probably scraping the HTML without preprocessing javascript or PHP.

How do we do that?

• Take care to not allow any links to the dev subdomains.

1. Note that the a2 cpanel domains page has the <meta robots noindex> tag.
2. When starting server development, manually add the <meta robots noindex> tag.
3. After completion, delete the worktree, and/or put up a fake page.
4. Maybe we only need one dev subdomain?

gitlab, voycgit, and webprod have a master branch only.
webdev and webapps have a master branch and also a temporary feature branch.

voycgit has no remotes.
gitlab has no remotes.
All other repositories have remote origin pointing to voycgit.
webprod also has remote gitlab.

get remote -v
$ origin ssh://voyccom@az1-ss8.a2hosting.com:7822/home/voyccom/voycgit/jslib.git	
$ gitlab https://gitlab.com/voyc/jslib.git

Note that use the ssh protocol; never the local protocol.

git clone ssh://voyccom@az1-ss8.a2hosting.com:7822/home/voyccom/voycgit/vote.git
git branch   # make sure you're in the master branch
git pull origin master
git submodule foreach git pull origin master

git branch popup         # create a feature branch
git checkout popup

<make changes>
git status
git add .
git commit -m 'New popup architecture'   # version control
git push origin popup      # remote backup

git switch master
git pull origin master 
git checkout popup
git rebase master               # merge modified master into popup branch, resolve conflicts here

git checkout master
git merge popup
git diff master..popup
git branch -d popup
git push origin master      # push to central
git push origin -d popup   # delete branch from central

git pull origin master
git push gitlab master

Trends in release management as of 2026.

• 50/72 rule. A commit message has three lines (title, blank, body). The first line is the title and it is 50 characters long. The second line is blank. The third and subsequent lines make up the body; they are bullets, and they are 72 characters long.
• Conventional Commits. The first line of the commit message is prefixed with a category: feat, fix, perf, style, refactor, test, build, chore.
• Semantic Versioning. Each release is numbered major.minor.patch, like 14.3.5. Modern developers don't bother with backward compatibility; when they break something they assign a new major version number. They also don't test or debug; when something breaks they fix it and give it a patch number.

more on Conventional Commits more on Semantic Versioning

Release history,

the changelog.md or release history is generated.

# All tags with their full messages, most recent first git tag -l –sort=-version:refname | xargs -I{} git show {} –no-patch –pretty=format:“%tag %*%(tag)%n%s%n%b%n—”

git for-each-ref –sort=-version:refname \

1. format=“%(refname:short)%0a%(contents)%0a—” \

refs/tags

For each commit:

• use conventional commit categorization https://en.wikipedia.org/wiki/Conventional_Commits_Specification

For each release:

• use semantic versioning
• use the 50/72 rule: multiline tag message

For commit and tag messages:

• use the 50/72 rule: