[aur-general] Request merge: mingw-w64-sqlite3 into mingw-w64-sqlite3 - Aur-general - lists.archlinux.org

newer
[aur-general] Bug Wrangler

[aur-general] Request merge: mingw-w64-sqlite3 into mingw-w64-sqlite3

older
[aur-general] Delete requests

Philip A Reimer

4 Feb 2014 4 Feb '14

10:11 a.m.

Hi Please merge. I renamed the package to match the name of sqlite in extra. https://aur.archlinux.org/packages/mingw-w64-sqlite3 into https://aur.archlinux.org/packages/mingw-w64-sqlite -ant32 http://amr.linuxd.org

Show replies by date

Daniel Micay

4 Feb 4 Feb

10:17 a.m.

On Tue, Feb 4, 2014 at 12:11 PM, Philip A Reimer wrote:

Hi Please merge. I renamed the package to match the name of sqlite in extra. https://aur.archlinux.org/packages/mingw-w64-sqlite3 into https://aur.archlinux.org/packages/mingw-w64-sqlite

-ant32 http://amr.linuxd.org

Using the sqlite3 naming seems like asking for trouble based on how upstream works.

SQLite4 is an alternative, not a replacement, for SQLite3. SQLite3 is not going away. SQLite3 and SQLite4 will be supported in parallel. The SQLite3 legacy will not be abandoned. SQLite3 will continue to be maintained and improved. But designers of new systems will now have the option to select SQLite4 instead of SQLite3 if desired.

I know the official repositories do this, but it doesn't work when upstream considers new releases to be independent projects and will continue development of the old one - even new features and performance enhancements. When SQLite4 is released as stable, there's going to be a problem.

Philip A Reimer

11:47 a.m.

On Tue, Feb 4, 2014 at 11:17 AM, Daniel Micay wrote:

On Tue, Feb 4, 2014 at 12:11 PM, Philip A Reimer wrote:

...
Hi Please merge. I renamed the package to match the name of sqlite in extra. https://aur.archlinux.org/packages/mingw-w64-sqlite3 into https://aur.archlinux.org/packages/mingw-w64-sqlite

-ant32 http://amr.linuxd.org

Using the sqlite3 naming seems like asking for trouble based on how upstream works.

...
SQLite4 is an alternative, not a replacement, for SQLite3. SQLite3 is not going away. SQLite3 and SQLite4 will be supported in parallel. The SQLite3 legacy will not be abandoned. SQLite3 will continue to be maintained and improved. But designers of new systems will now have the option to select SQLite4 instead of SQLite3 if desired.

I know the official repositories do this, but it doesn't work when upstream considers new releases to be independent projects and will continue development of the old one - even new features and performance enhancements.

When SQLite4 is released as stable, there's going to be a problem.

I was not aware that SQLite4 wouldn't be a replacement. If this package should be named sqlite3 then the new package needs to be deleted. I'll be waiting for a TU to either delete mingw-w64-sqlite or merge mingw-w64-sqlite3 into it.

Philip A Reimer

6 Feb 6 Feb

8:14 a.m.

---------- Forwarded message ---------- From: Andreas Radke Date: Thu, Feb 6, 2014 at 1:52 AM Subject: Re: Delete Request: mingw-w64-sqlite To: Philip A Reimer Am Wed, 5 Feb 2014 14:39:32 -0600 schrieb Philip A Reimer :

Should sqlite be renamed to sqlite3?

-ant32

Arch policy is to keep the unversioned name for the latest release. This will become sqlite v4 when it comes out. At the same time we will rename the current release to sqlite3 if still required and we will rebuild all packages to depend on new v4 or old v3 version. Right now sqlite v3 is the current release and stays without a version number. PS: We have sqlite2 in community and did it the same way in the past. See also python releases and all the other stuff. -Andy

3739

Age (days ago)

3741

Last active (days ago)

Download

3 comments

2 participants

tags

participants (2)

Daniel Micay
Philip A Reimer