(Are you sure you want a non-URI- and non-shell-compatible character in your filenames?)

[rgwilton]

This was raised by Carsten.

[cabo]

$ rm my-module#3.0.2.yang
my-module: not found

https://my--server/my-module#3.0.2.yang
➔
404 https://my--server/my-module not found

[xorrkaz]

Thanks, @cabo . In our tests we tried bash, zsh, tcsh, and BSD sh. All of them worked. A leading '#' would break, however.

[cabo]

Right, bash says:

COMMENTS
       In a non-interactive shell, or an interactive shell in which the inter-
       active_comments option to the  shopt  builtin  is  enabled  (see  SHELL
       BUILTIN  COMMANDS  below), a word beginning with # causes that word and
       all remaining characters on that line to be  ignored.   An  interactive
       shell  without  the  interactive_comments option enabled does not allow
       comments.  The interactive_comments option is on by default in interac-
       tive shells.

My URI comment remains.

[jsterne]

Let's bring this back to the list.

Servers would handle escaping (i.e. provide the escaping, or convert the requests)
Publishers of URLs would need to publish '%23' instead of '#'.

Might a makefile also have troubles ? Is this likely a big common problem ? More of a developer's problem. (i.e. we won't prioritize that as highly)

use a non-single char ? @v3.0.1 (might assume the char after the @ is a date)

Other characters to consider:
my-module#3.3.2
my-module%3.2.2 - perhaps another candidate ? same URL impact (no impact on makefiles, it is a common searching char, pattern rule).
my-module+3.2.3 same URL impact (no impact on makefiles, except perhaps in windows ? regexp char)
my-module~3.2.3 same URL impact (no impact on makefiles, maybe a pattern thing e.g. VIM)
my-module-123 2008-01-02 3.2.1 3-2-1 -revision-label. Move this to YANG Semver -3.2.3 or _3.2.3
-.yang
my-module-2-3-4-3.2.3.yang
doesn't work well for "revision-label". May work OK for YANG semver specifically.

my-module!3.2.3 <- bad in bash (tries command 3 in history)
my-module$3.2.2 <- variable expansion

my-module@2008-01-02 <- fine for URLs (but escaped in shells)

Conclusion: still prefer the #. It is the lesser of all the evils.

[xorrkaz]

Email sent to the list. Rob and I went back and forth. While encoding is not ideal, the same happens for '@' in certain cases (bash escape this for one and URLs may encode it as well). I didn't see any strong objections to '#'. While tooling will need to change to support the '#', tools not yet made the change would be confused by overloading '@'.

[xorrkaz]

Sent a final conclusion email to the list and did not get any further replies. Closing with decision that we will stick with '#'.