mirror of
https://github.com/PurpurMC/Purpur.git
synced 2026-02-17 16:37:43 +01:00
[ci-skip] Tuinity license change
This commit is contained in:
@@ -3,479 +3,170 @@ From: Spottedleaf <Spottedleaf@users.noreply.github.com>
|
||||
Date: Fri, 14 Dec 2018 21:53:58 -0800
|
||||
Subject: [PATCH] Tuinity Server Changes
|
||||
|
||||
Brand changes
|
||||
GNU LESSER GENERAL PUBLIC LICENSE
|
||||
Version 3, 29 June 2007
|
||||
|
||||
MC-Dev fixes
|
||||
Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.
|
||||
|
||||
Util patch
|
||||
This version of the GNU Lesser General Public License incorporates
|
||||
the terms and conditions of version 3 of the GNU General Public
|
||||
License, supplemented by the additional permissions listed below.
|
||||
|
||||
Tuinity Server Config
|
||||
|
||||
Multi-Threaded Server Ticking Vanilla
|
||||
|
||||
This patch is the vanilla server changes
|
||||
|
||||
Currently a placeholder patch.
|
||||
|
||||
Multi-Threaded ticking CraftBukkit
|
||||
|
||||
These are the changes to CB
|
||||
|
||||
Currently a placeholder patch.
|
||||
|
||||
Add soft async catcher
|
||||
|
||||
Must be enabled via -Dtuinity.strict-thread-checks=true
|
||||
|
||||
Delay chunk unloads
|
||||
|
||||
Chunk unloads are now delayed by 1s. Specifically, ticket level
|
||||
reduction is delayed by 1s. This is done to allow players to
|
||||
teleport and have their pets follow them, as the chunks will no longer
|
||||
unload or have entity ticking status removed.
|
||||
|
||||
It's also targetted to reduce performance regressions when
|
||||
plugins or edge cases in code do not spam sync loads since chunks
|
||||
without tickets get unloaded immediately.
|
||||
|
||||
Configurable under `delay-chunkunloads-by` in config.
|
||||
|
||||
This patch replaces the paper patch as the paper patch only
|
||||
affects player loaded chunks, when we want to target all
|
||||
loads.
|
||||
|
||||
Attempt to recalculate regionfile header if it is corrupt
|
||||
|
||||
Instead of trying to relocate the chunk, which is seems to never
|
||||
be the correct choice, so we end up duplicating or swapping chunks,
|
||||
we instead drop the current regionfile header and recalculate -
|
||||
hoping that at least then we don't swap chunks, and maybe recover
|
||||
them all.
|
||||
|
||||
Lag compensate block breaking
|
||||
|
||||
Use time instead of ticks if ticks fall behind
|
||||
|
||||
Update version fetcher repo
|
||||
|
||||
Sets the target github repo to Tuinity in the version checker. Also disables the jenkins build lookups.
|
||||
|
||||
Per World Spawn Limits
|
||||
|
||||
Detail more information in watchdog dumps
|
||||
|
||||
- Dump position, world, velocity, and uuid for currently ticking entities
|
||||
- Dump player name, player uuid, position, and world for packet handling
|
||||
|
||||
Execute chunk tasks mid-tick
|
||||
|
||||
This will help the server load chunks if tick times are high.
|
||||
|
||||
Change writes to use NORMAL priority rather than LOW
|
||||
|
||||
Should limit build up of I/O tasks, or at least properly
|
||||
indicate to server owners that I/O is falling behind
|
||||
|
||||
Allow controlled flushing for network manager
|
||||
|
||||
Only make one flush call when emptying the packet queue too
|
||||
|
||||
This patch will be used to optimise out flush calls in later
|
||||
patches.
|
||||
|
||||
Consolidate flush calls for entity tracker packets
|
||||
|
||||
Most server packets seem to be sent from here, so try to avoid
|
||||
expensive flush calls from them.
|
||||
|
||||
This change was motivated due to local testing:
|
||||
|
||||
- My server spawn has 130 cows in it (for testing a prev. patch)
|
||||
- Try to let 200 players join spawn
|
||||
|
||||
Without this change, I could only get 20 players on before they
|
||||
all started timing out due to the load put on the Netty I/O threads.
|
||||
|
||||
With this change I could get all 200 on at 0ms ping.
|
||||
|
||||
(one of the primary issues is that my CPU is kinda trash, and having
|
||||
4 extra threads at 100% is just too much for it).
|
||||
|
||||
So in general this patch should reduce Netty I/O thread load.
|
||||
|
||||
Time scoreboard search
|
||||
|
||||
Plugins leaking scoreboards will make this very expensive,
|
||||
let server owners debug it easily
|
||||
|
||||
Make CallbackExecutor strict again
|
||||
|
||||
The correct fix for double scheduling is to avoid it. The reason
|
||||
this class is used is because double scheduling causes issues
|
||||
elsewhere, and it acts as an explicit detector of what double
|
||||
schedules. Effectively, use the callback executor as a tool of
|
||||
finding issues rather than hiding these issues.
|
||||
|
||||
This patch also reverts incorrect use(s) of the class by paper.
|
||||
|
||||
- getChunkFutureAsynchronously
|
||||
There is no risk at all of recursion. The future is executed on
|
||||
the chunk provider's thread queue, the same place general plugin
|
||||
load callbacks are executed on. Forcing the task execution into
|
||||
the callback executor also prevents the future from catching
|
||||
any exception thrown from it.
|
||||
|
||||
Optimise entity hard collision checking
|
||||
|
||||
Very few entities actually hard collide, so store them in their own
|
||||
entity slices and provide a special getEntites type call just for them.
|
||||
This reduces entity collision checking impact (in my testing) by 25%
|
||||
for crammed entities (shove 130 cows into an 8x6 area in one chunk).
|
||||
Less crammed entities are likely to show significantly less benefit.
|
||||
Effectively, this patch optimises crammed entity situations.
|
||||
|
||||
Improved oversized chunk data packet handling
|
||||
|
||||
Now target all TE data, except for TE's that do not have
|
||||
update packets.
|
||||
|
||||
This patch relies upon the improve extra packet handling
|
||||
patch, as we now use PacketPlayOutMapChunk as an extra packet.
|
||||
See its patch notes for further details.
|
||||
|
||||
Reduce iterator allocation from chunk gen
|
||||
|
||||
Replace via iterating over an array
|
||||
|
||||
Prevent long map entry creation in light engine
|
||||
|
||||
Use fastiterator to prevent it
|
||||
|
||||
Highly optimise single and multi-AABB VoxelShapes and collisions
|
||||
|
||||
Reduce allocation rate from crammed entities
|
||||
|
||||
Optimise chunk tick iteration
|
||||
|
||||
Use a dedicated list of entity ticking chunks to reduce the cost
|
||||
|
||||
Use entity ticking chunk map for entity tracker
|
||||
|
||||
Should bring us back in-line with tracker performance
|
||||
before the loaded entity list reversion.
|
||||
|
||||
Improve paper prevent moving into unloaded chunk check
|
||||
|
||||
Check the AABB of the move
|
||||
|
||||
Improve async tp to not load chunks when crossing worlds
|
||||
|
||||
Fixes an issue where a getCubes call would load neighbouring chunks.
|
||||
Loads less chunks than paper's implementation
|
||||
|
||||
Revert getChunkAt(Async) retaining chunks for long periods of time
|
||||
|
||||
Rework PlayerChunk main thread checks
|
||||
|
||||
These need to fail instead of continuing, as hiding these errors
|
||||
the way paper has is just going to allow unexpected reordering
|
||||
of callbacks.
|
||||
|
||||
For example, thanks to this patch incorrect future
|
||||
completion (completion of the world gen future,
|
||||
PlayerChunkMap#b(PlayerChunk, ChunkStatus)) was detected and fixed.
|
||||
|
||||
Allow Entities to be removed from a world while ticking
|
||||
|
||||
Fixes issues like disconnecting players while ticking them, or
|
||||
issues where teleporting players across worlds while ticking.
|
||||
|
||||
Also allows us to run mid tick while ticking entities.
|
||||
|
||||
Prevent unload() calls removing tickets for sync loads
|
||||
|
||||
Optimise collision checking in player move packet handling
|
||||
|
||||
Move collision logic to just the hasNewCollision call instead of getCubes + hasNewCollision
|
||||
|
||||
Manually inline methods in BlockPosition
|
||||
|
||||
Separate lookup locking from state access in UserCache
|
||||
|
||||
Prevent lookups from stalling simple state access/write calls
|
||||
|
||||
Distance manager tick timings
|
||||
|
||||
Recently this has been taking up more time, so add a timings to
|
||||
really figure out how much.
|
||||
|
||||
Name craft scheduler threads according to the plugin using them
|
||||
|
||||
Provides quick access to culprits running far more threads than
|
||||
they should be
|
||||
|
||||
Fix swamp hut cat generation deadlock
|
||||
|
||||
The worldgen thread will attempt to get structure references
|
||||
via the world's getChunkAt method, which is fine if the gen is
|
||||
not cancelled - but if the chunk was unloaded, the call will block
|
||||
indefinitely. Instead of using the world state, we use the already
|
||||
supplied generatoraccess which will always have the chunk available.
|
||||
|
||||
Range check flag dirty calls in PlayerChunk
|
||||
|
||||
Simply return.
|
||||
|
||||
Optimise tab complete
|
||||
|
||||
Some of the toLowerCase calls can be expensive.
|
||||
|
||||
Do not allow ticket level changes while unloading playerchunks
|
||||
|
||||
Sync loading the chunk at this stage would cause it to load
|
||||
older data, as well as screwing our region state.
|
||||
|
||||
Make sure inlined getChunkAt has inlined logic for loaded chunks
|
||||
|
||||
Tux did some profiling some time ago and showed that the
|
||||
previous getChunkAt method which had inlined logic for loaded
|
||||
chunks did get inlined, but the standard CPS.getChunkAt
|
||||
method was not inlined.
|
||||
|
||||
Paper recently reverted this optimisation, so it's been reintroduced
|
||||
here.
|
||||
|
||||
Add packet limiter config
|
||||
|
||||
Example config:
|
||||
packet-limiter:
|
||||
kick-message: '&cSent too many packets'
|
||||
limits:
|
||||
all:
|
||||
interval: 7.0
|
||||
max-packet-rate: 500.0
|
||||
PacketPlayInAutoRecipe:
|
||||
interval: 4.0
|
||||
max-packet-rate: 5.0
|
||||
action: DROP
|
||||
|
||||
all section refers to all incoming packets, the action for all is
|
||||
hard coded to KICK.
|
||||
|
||||
For specific limits, the section name is the class's name,
|
||||
and an action can be defined: DROP or KICK
|
||||
|
||||
If interval or rate are less-than 0, the limit is ignored
|
||||
|
||||
Optimise closest entity lookup
|
||||
|
||||
Rewrites the entity slice storage so that entity by
|
||||
class lookups look through less entities in total.
|
||||
|
||||
Also optimise the nearest entity by class method
|
||||
used by entity AI as well.
|
||||
|
||||
As a sidenote, this entity slice implementation
|
||||
removes the async catchers because it has been
|
||||
designed to be MT-Safe for reads off of other
|
||||
threads.
|
||||
|
||||
Optimise nearby player lookups
|
||||
|
||||
Use a distance map to map out close players.
|
||||
Note that it's important that we cache the distance map value per chunk
|
||||
since the penalty of a map lookup could outweigh the benefits of
|
||||
searching less players (as it basically did in the outside range patch).
|
||||
|
||||
Remove streams for villager AI
|
||||
|
||||
POI searching:
|
||||
Turns out chaining a lot of streams together has inane amounts of
|
||||
overheard. Use the good ol iterator method to remove that overhead.
|
||||
|
||||
The rest is just standard stream removal.
|
||||
|
||||
Also remove streams for poi searching in some zombie pathfinding.
|
||||
|
||||
Don't lookup fluid state when raytracing
|
||||
|
||||
Just use the iblockdata already retrieved, removes a getType call.
|
||||
|
||||
Reduce pathfinder branches
|
||||
|
||||
Reduce static path type detection to simple lazy-init fields
|
||||
|
||||
Add Velocity natives for encryption and compression
|
||||
|
||||
Optimise non-flush packet sending
|
||||
|
||||
Places like entity tracking make heavy use of packet sending,
|
||||
and internally netty will use some very expensive thread wakeup
|
||||
calls when scheduling.
|
||||
|
||||
Thanks to various hacks in ProtocolLib as well as other
|
||||
plugins, we cannot simply use a queue of packets to group
|
||||
send on execute. We have to call execute for each packet.
|
||||
|
||||
Tux's suggestion here is exactly what was needed - tag
|
||||
the Runnable indicating it should not make a wakeup call.
|
||||
|
||||
Big thanks to Tux for making this possible as I had given
|
||||
up on this optimisation before he came along.
|
||||
|
||||
Locally this patch drops the entity tracker tick by a full 1.5x.
|
||||
|
||||
Do not retain playerchunkmap instance in light thread factory
|
||||
|
||||
The executor returned is finalizable and of course
|
||||
that causes issues.
|
||||
|
||||
Do not load chunks during a crash report
|
||||
|
||||
This causes deadlocks in some cases when generating
|
||||
crash reports.
|
||||
|
||||
Fixes https://github.com/Spottedleaf/Tuinity/issues/215
|
||||
|
||||
Improve abnormal server shutdown process
|
||||
|
||||
- When we're trying to kill the main thread from watchdog,
|
||||
step up the stop() spamming after 15s to really kill the main thread.
|
||||
|
||||
- Do not wait for window disposing when disposing of the server
|
||||
gui. It looks like during sigint shutdown there can be some
|
||||
deadlock between the server thread and awt shutdown thread here.
|
||||
|
||||
Copy passenger list in enderTeleportTo
|
||||
|
||||
Fixes https://github.com/Spottedleaf/Tuinity/issues/208
|
||||
|
||||
Revert MC-4 fix
|
||||
|
||||
When messing around with collisions, I ran into problems where
|
||||
entity position was off by ULP and that caused clipping problems.
|
||||
Now, the collision epsilon is 1.0e-7 to account for those errors.
|
||||
|
||||
But this patch is going to cause problems on the order of 1.0e-4.
|
||||
|
||||
I do not want to deal with clipping problems. The very fact it works
|
||||
shows it's causing the clipping to occur serverside.
|
||||
|
||||
Prevent light queue overfill when no players are online
|
||||
|
||||
block changes don't queue light updates (and they shouldn't)
|
||||
|
||||
Don't allow StructureLocateEvent to change worlds
|
||||
|
||||
Callers and even the function itself aren't expecting
|
||||
this to happen
|
||||
|
||||
Properly handle cancellation of projectile hit event
|
||||
|
||||
Subclasses override and run logic. Some of this logic destroys
|
||||
the projectile as well, which wouldn't be fitting for cancellation.
|
||||
|
||||
Rewrite the light engine
|
||||
|
||||
The standard vanilla light engine is plagued by
|
||||
awful performance. Paper's changes to the light engine
|
||||
help a bit, however they appear to cause some lighting
|
||||
errors - most easily noticed in coral generation.
|
||||
|
||||
The vanilla light engine's is too abstract to be modified -
|
||||
so an entirely new implementation is required to fix the
|
||||
performance and lighting errors.
|
||||
|
||||
The new implementation is designed primarily to optimise
|
||||
light level propagations (increase and decrease). Unlike
|
||||
the vanilla light engine, this implementation tracks more
|
||||
information per queued value when performing a
|
||||
breadth first search. Vanilla just tracks coordinate, which
|
||||
means every time they handle a queued value, they must
|
||||
also determine the coordinate's target light level
|
||||
from its neighbours - very wasteful, especially considering
|
||||
these checks read neighbour block data.
|
||||
The new light engine tracks both position and target level,
|
||||
as well as whether the target block needs to be read at all
|
||||
(for checking sided propagation). So, the work done per coordinate
|
||||
is significantly reduced because no work is done for calculating
|
||||
the target level.
|
||||
In my testing, the block get calls were reduced by approximately
|
||||
an order of magnitude. However, the light read checks were only
|
||||
reduced by approximately 2x - but this is fine, light read checks
|
||||
are extremely cheap compared to block gets.
|
||||
|
||||
Generation testing showed that the new light engine improved
|
||||
total generation (not lighting itself, but the whole generation process)
|
||||
by 2x. According to cpu time, the light engine itself spent 10x less time
|
||||
lighting chunks for generation.
|
||||
|
||||
Optimise WorldServer#notify
|
||||
|
||||
Iterating over all of the navigators in the world is pretty expensive.
|
||||
Instead, only iterate over navigators in the current region that are
|
||||
eligible for repathing.
|
||||
|
||||
Actually unload POI data
|
||||
|
||||
While it's not likely for a poi data leak to be meaningful,
|
||||
sometimes it is.
|
||||
|
||||
This patch also prevents the saving/unloading of POI data when
|
||||
world saving is disabled.
|
||||
|
||||
Send full pos packets for hard colliding entities
|
||||
|
||||
Prevent collision problems due to desync (i.e boats)
|
||||
|
||||
Configurable under
|
||||
`send-full-pos-for-hard-colliding-entities`
|
||||
|
||||
Fix chunks refusing to unload at low TPS
|
||||
|
||||
The full chunk future is appended to the chunk save future, but
|
||||
when moving to unloaded ticket level it is not being completed with
|
||||
the empty chunk access, so the chunk save must wait for the full
|
||||
chunk future to complete. We can simply schedule to the immediate
|
||||
executor to get this effect, rather than the main mailbox.
|
||||
|
||||
Fix incorrect isRealPlayer init
|
||||
|
||||
Some plugins, namely ProtocolSupport, don't route to where
|
||||
paper placed their logic. So it wont correctly set in this case.
|
||||
|
||||
Fix by moving it to a different place.
|
||||
|
||||
Do not run raytrace logic for AIR
|
||||
|
||||
Saves approx. 5% for the raytrace call, as most (expensive)
|
||||
raytracing tends to go through air and returning early is an
|
||||
easy win. The remaining problems with this function
|
||||
are mostly with the block getting itself.
|
||||
|
||||
Make entity tracker use highest range of passengers
|
||||
|
||||
This should prevent people from having to up their animal range
|
||||
just so players riding horses or whatever can be seen at the
|
||||
configured player range.
|
||||
|
||||
Do not allow the server to unload chunks at request of plugins
|
||||
|
||||
In general the chunk system is not well suited for this behavior,
|
||||
especially if it is called during a chunk load. The chunks pushed
|
||||
to be unloaded will simply be unloaded next tick, rather than
|
||||
immediately.
|
||||
|
||||
Do not run close logic for inventories on chunk unload
|
||||
|
||||
Still call the event and change the active container though. We
|
||||
want to avoid close logic because it's possible to load the
|
||||
chunk through it. This should also be OK from a leak prevention/
|
||||
state desync POV because the TE is getting unloaded anyways.
|
||||
|
||||
Fix NPE in pickup logic for arrow
|
||||
|
||||
Apparently the shooter can be null for tridents returning to players.
|
||||
0. Additional Definitions.
|
||||
|
||||
As used herein, "this License" refers to version 3 of the GNU Lesser
|
||||
General Public License, and the "GNU GPL" refers to version 3 of the GNU
|
||||
General Public License.
|
||||
|
||||
"The Library" refers to a covered work governed by this License,
|
||||
other than an Application or a Combined Work as defined below.
|
||||
|
||||
An "Application" is any work that makes use of an interface provided
|
||||
by the Library, but which is not otherwise based on the Library.
|
||||
Defining a subclass of a class defined by the Library is deemed a mode
|
||||
of using an interface provided by the Library.
|
||||
|
||||
A "Combined Work" is a work produced by combining or linking an
|
||||
Application with the Library. The particular version of the Library
|
||||
with which the Combined Work was made is also called the "Linked
|
||||
Version".
|
||||
|
||||
The "Minimal Corresponding Source" for a Combined Work means the
|
||||
Corresponding Source for the Combined Work, excluding any source code
|
||||
for portions of the Combined Work that, considered in isolation, are
|
||||
based on the Application, and not on the Linked Version.
|
||||
|
||||
The "Corresponding Application Code" for a Combined Work means the
|
||||
object code and/or source code for the Application, including any data
|
||||
and utility programs needed for reproducing the Combined Work from the
|
||||
Application, but excluding the System Libraries of the Combined Work.
|
||||
|
||||
1. Exception to Section 3 of the GNU GPL.
|
||||
|
||||
You may convey a covered work under sections 3 and 4 of this License
|
||||
without being bound by section 3 of the GNU GPL.
|
||||
|
||||
2. Conveying Modified Versions.
|
||||
|
||||
If you modify a copy of the Library, and, in your modifications, a
|
||||
facility refers to a function or data to be supplied by an Application
|
||||
that uses the facility (other than as an argument passed when the
|
||||
facility is invoked), then you may convey a copy of the modified
|
||||
version:
|
||||
|
||||
a) under this License, provided that you make a good faith effort to
|
||||
ensure that, in the event an Application does not supply the
|
||||
function or data, the facility still operates, and performs
|
||||
whatever part of its purpose remains meaningful, or
|
||||
|
||||
b) under the GNU GPL, with none of the additional permissions of
|
||||
this License applicable to that copy.
|
||||
|
||||
3. Object Code Incorporating Material from Library Header Files.
|
||||
|
||||
The object code form of an Application may incorporate material from
|
||||
a header file that is part of the Library. You may convey such object
|
||||
code under terms of your choice, provided that, if the incorporated
|
||||
material is not limited to numerical parameters, data structure
|
||||
layouts and accessors, or small macros, inline functions and templates
|
||||
(ten or fewer lines in length), you do both of the following:
|
||||
|
||||
a) Give prominent notice with each copy of the object code that the
|
||||
Library is used in it and that the Library and its use are
|
||||
covered by this License.
|
||||
|
||||
b) Accompany the object code with a copy of the GNU GPL and this license
|
||||
document.
|
||||
|
||||
4. Combined Works.
|
||||
|
||||
You may convey a Combined Work under terms of your choice that,
|
||||
taken together, effectively do not restrict modification of the
|
||||
portions of the Library contained in the Combined Work and reverse
|
||||
engineering for debugging such modifications, if you also do each of
|
||||
the following:
|
||||
|
||||
a) Give prominent notice with each copy of the Combined Work that
|
||||
the Library is used in it and that the Library and its use are
|
||||
covered by this License.
|
||||
|
||||
b) Accompany the Combined Work with a copy of the GNU GPL and this license
|
||||
document.
|
||||
|
||||
c) For a Combined Work that displays copyright notices during
|
||||
execution, include the copyright notice for the Library among
|
||||
these notices, as well as a reference directing the user to the
|
||||
copies of the GNU GPL and this license document.
|
||||
|
||||
d) Do one of the following:
|
||||
|
||||
0) Convey the Minimal Corresponding Source under the terms of this
|
||||
License, and the Corresponding Application Code in a form
|
||||
suitable for, and under terms that permit, the user to
|
||||
recombine or relink the Application with a modified version of
|
||||
the Linked Version to produce a modified Combined Work, in the
|
||||
manner specified by section 6 of the GNU GPL for conveying
|
||||
Corresponding Source.
|
||||
|
||||
1) Use a suitable shared library mechanism for linking with the
|
||||
Library. A suitable mechanism is one that (a) uses at run time
|
||||
a copy of the Library already present on the user's computer
|
||||
system, and (b) will operate properly with a modified version
|
||||
of the Library that is interface-compatible with the Linked
|
||||
Version.
|
||||
|
||||
e) Provide Installation Information, but only if you would otherwise
|
||||
be required to provide such information under section 6 of the
|
||||
GNU GPL, and only to the extent that such information is
|
||||
necessary to install and execute a modified version of the
|
||||
Combined Work produced by recombining or relinking the
|
||||
Application with a modified version of the Linked Version. (If
|
||||
you use option 4d0, the Installation Information must accompany
|
||||
the Minimal Corresponding Source and Corresponding Application
|
||||
Code. If you use option 4d1, you must provide the Installation
|
||||
Information in the manner specified by section 6 of the GNU GPL
|
||||
for conveying Corresponding Source.)
|
||||
|
||||
5. Combined Libraries.
|
||||
|
||||
You may place library facilities that are a work based on the
|
||||
Library side by side in a single library together with other library
|
||||
facilities that are not Applications and are not covered by this
|
||||
License, and convey such a combined library under terms of your
|
||||
choice, if you do both of the following:
|
||||
|
||||
a) Accompany the combined library with a copy of the same work based
|
||||
on the Library, uncombined with any other library facilities,
|
||||
conveyed under the terms of this License.
|
||||
|
||||
b) Give prominent notice with the combined library that part of it
|
||||
is a work based on the Library, and explaining where to find the
|
||||
accompanying uncombined form of the same work.
|
||||
|
||||
6. Revised Versions of the GNU Lesser General Public License.
|
||||
|
||||
The Free Software Foundation may publish revised and/or new versions
|
||||
of the GNU Lesser General Public License from time to time. Such new
|
||||
versions will be similar in spirit to the present version, but may
|
||||
differ in detail to address new problems or concerns.
|
||||
|
||||
Each version is given a distinguishing version number. If the
|
||||
Library as you received it specifies that a certain numbered version
|
||||
of the GNU Lesser General Public License "or any later version"
|
||||
applies to it, you have the option of following the terms and
|
||||
conditions either of that published version or of any later version
|
||||
published by the Free Software Foundation. If the Library as you
|
||||
received it does not specify a version number of the GNU Lesser
|
||||
General Public License, you may choose any version of the GNU Lesser
|
||||
General Public License ever published by the Free Software Foundation.
|
||||
|
||||
If the Library as you received it specifies that a proxy can decide
|
||||
whether future versions of the GNU Lesser General Public License shall
|
||||
apply, that proxy's public statement of acceptance of any version is
|
||||
permanent authorization for you to choose that version for the
|
||||
Library.
|
||||
|
||||
diff --git a/pom.xml b/pom.xml
|
||||
index 9ba379b7e3ee3bc8c6d2c8ec46213c404c73d682..e83e4241a56fe131a75fe21cc1518992c089da2c 100644
|
||||
|
||||
Reference in New Issue
Block a user