Lines Matching refs:release

110 SYMBOL_VERSION SUNW_1.1 {	# first release of libwombat, Solaris 9
126 There should be at most one version name for each release of Solaris,
130 in a given Solaris release, no new version name should be generated
131 for that release.  If multiple updates are made to the library at
132 different points in the development of a given release of Solaris,
133 only one version should be used for the entire release.
205 The first engineer to update the existing mapfile-vers file in a release needs
219 incremented at most once per (external to Sun) release of the library.
247 4.3 Adding new public interfaces in an update release
249 Adding new public interfaces in an update release requires careful
250 coordination with the next marketing release currently under development.
251 Multiple updates ship during the period before the next marketing release
253 interfaces in the next marketing release until late in its development
255 interfaces added to the next marketing release will be added to an update.
265 minor release "N+1" to reflect its inclusion of micro releases will
270 SYMBOL_VERSION SUNW_1.4 {	# release N+1
275 SYMBOL_VERSION SUNW_1.3.2 {	# micro release 2 (e.g., release NU3)
280 SYMBOL_VERSION SUNW_1.3.1 {	# micro release 1 (e.g., release NU2)
285 SYMBOL_VERSION SUNW_1.3 {	# release N
290 SYMBOL_VERSION SUNW_1.2 {	# release N-1
295 SYMBOL_VERSION SUNW_1.1 {	# first release
314 of the update release and next marketing release must be modified to be
316 release until the putback to the update release has occurred, to avoid
361 interface must be put into a set associated with the current Public release
365 last release of Solaris was SUNW_1.23, any new ABI introduced in the next
366 release would be put into a version called SUNW_1.24.  Therefore, whether
397 an existing library (where m.n is the next release version; i.e., if the
423 SYMBOL_VERSION SUNW_1.1 {	# first release of libfoo