[Slackbuilds-users] Creating First Slackbuilds and Github

[Jeremy Hansen]

On Sun, Mar 20, 2022, 4:58 PM Ruben Schuller <sb at rbn.im> wrote:

> Hi,
>
> 2022-03-20 "B. Watson" <urchlay at slackware.uk>:
>
> > On Sat, 19 Mar 2022, Ruben Schuller wrote:
> > >
> > > ZIPVER="1369d247e3d2bc697892795dea8cc1713344749f"
> > >
> > > for the version I'd either go with the date like 220319 if there
> > > aren't multiple commits on that date, or with the short-hash of
> > > git:
> >
> > Recommendations... in fact I'm begging you: if you're going to use
> > a git commit, *please* include the date in YYMMDD format in your
> > VERSION number. Example:
> >
> > VERSION="20220319+1369d24"
> >
> > Notice the 4-digit year comes first... the point of doing it this way
> > is that a user can easily tell which version is newer, when looking
> > at multiple packages. If you use only the git commit hash, those are
> > effectively random, there's no sense of which is newest.
> >
> > The SlackBuild can split up the VERSION variable as needed.
> >
> > Also, while I'm thinking about it: VERSION *must* be a constant that
> > can be overridden by the environment. Example:
> >
> > VERSION=${VERSION:-3.4.1}
>
> Very good point, including the date never hurts.
>
> > *Please* don't try to get clever and do stuff like:
> >
> > COMMIT=1369d247e3d2bc697892795dea8cc1713344749f
> > VERSION="$( echo $COMMIT | head -c7 )"
>
> Note, for completeness, that the git short hash might be longer than
> seven characters because of collisions. The git command figures that
> out. Don't just shorten it :)
>

On SBo, it won't matter if there's collisions. It's simply a reference to a
version that exists on SBo. If there's collisions within the upstream repo,
it won't affect the version we have on SBo.

Jeremy

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20220320/bb201e6f/attachment.htm>