Library to generate unique identifiers
This library provides the interface BjoernGoetschke\UniqueID\GeneratorInterface
to generate
unique identifiers.
Software that needs unique identifiers can use an object that implements the interface
BjoernGoetschke\UniqueID\GeneratorInterface
to request unique identifiers on demand by calling the
generate()
method.
/** @var \BjoernGoetschke\UniqueID\GeneratorInterface $generator */
// `$uid` will contain random uid string that is between 10 and 50 characters long
$uid = $generator->generate(10, 50);
The library is available via Composer:
composer require bjoern-goetschke/unique-id:^2.0
Releases will be numbered with the following format using semantic versioning:
<major>.<minor>.<patch>
And constructed with the following guidelines:
For more information on semantic versioning, please visit http://semver.org/.
See API usage and backwards compatibility for detailed information about how to use the library in a way that will not break on updates and what is considered a backward incompatible change.
The library is released under the BSD-2-Clause license. You can find a copy of this license in LICENSE.txt.
Information about the intended usage of interfaces, classes, methods, etc. is specified with the @api
tag.
If an element does not contain the @api
tag it should be considered internal and usage may break at any time.
One exception to this rule are special elements like constructors, destructors or other hook methods that are defined
by the programming language. These elements will not have their own @api
tag but can be considered as if they have
the same @api
tag as the class or whatever other element they belong to.
@api usage
major
-releasesmajor
-releasesminor
-releases should be ok most of the time
(will break if a non-private method has been added to the base class that was also declared
in the extending class)major
-releasesminor
-releases should be ok most of the time
(will break if an optional argument has been added to the method in the base-class)major
-releasesmajor
-releasesminor
-releases should be ok most of the time
(will break if new methods have been added to the interface)minor
-releases should be ok most of the time
(will break if a method has been added to the base interface that was also declared
in the extending interface)@api extend
major
-releasesmajor
-releasesminor
-releases, but it should be ok most of the time and may only break on major
-releases
(will break if a non-private method has been added to the base class that was also declared in the
extending class)major
-releasesmajor
-releasesmajor
-releasesmajor
-releasesmajor
-releasesmajor
-releases@api stable
major
-releases, this means that except some minor internal
changes or bugfixes the code will just never change at all@api internal
patch
-releases should be ok most of the time