Product Backlog is for future releases then Sprint Backlog is about "Done" items

From the Scrum Guide:

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. 

The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint... As new work is required, the Development Team adds it to the Sprint Backlog. 

Thanks Timothy. If you could clear my doubt about following two questions, I will really appreciate it.

1. What happens to "Product Backlog" items that has been declared "Done" after, say, just now concluded Sprint? Are they taken out of "Product Backlog"? If yes, then how these done items log are maintained in the Scrum?

2. It is clear that each sprint has its unique "Sprint Backlog". So is it that sum of all "Sprint Backlogs" provide a comprehensive list of of all done items? Saying so, implies that, each Sprint Backlog might have been maintained for historical purpose.

The Product Backlog is the single repository where the requirements, features, changes, etc.. are documented and prioritised.

Sprint Backlog is the subset of the Product Backlog which shows the current state of In progress work and eventually Done.

To answer your question what happens to done, its very similar to maintaining the status of each requirement . In your Product Backlog either you have a column to state its Done after sprint review for the items accepted, create a separate section in your repository (sheet in excel, table in word. etc..) to track the Done items.

Who would need that "log" of completed backlog items, and for what "historical purpose" would they use it? 

The Scrum Team, because, Scrum is based on Empiricism. 

Would not the Scrum team or teams in an organization like to inspect and adapt based on the historical data of other successful projects/products?

If Product Backlog also keeps done items then may be the statement in Scrum Guide that states 

"The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases."

need modification to reflect the reality, that, it contains Done items and future requirements both.

Manoj, the Product Backlog should never contain "Done" items.   The Product Backlog doesn't even contain active sprint items.   Those PBI's are moved to and reside in the Sprint Backlog once they are accepted by the team for the sprint.

Perhaps it would be easier to think of a Product Backlog as a long "to do" list, and a Sprint Backlog as a "do now" list.   Can items exist in both places?   Should they?   When items are completed and crossed off of the "do now" list, do they return to the "to do" list?   What is gained by maintaining both open and completed items in your "to do" list?

When an item is completed in a sprint, it is up to the team/organization how they want to maintain that information going forward, but it is never returned to the Product Backlog.

Sounds great. Thank you so much, Timothy.

Empiricism is based on the evidence of value delivered, not on a log of Product Backlog items or other proxy measure. 

That also depends on what attributes someone define in Product Backlog.

I was going through "A Lightweight Guide to the Theory and Practice of Scrum Version 2.0". In this small document on Page 6, figure 2, there is a sample "Product Backlog".

It shows that Product Backlog might define "Initial Size Estimate". Similarly, if in Sprint Backlog the actual size required to implement a feature is kept, then would not this data along with other factors like skills (technical and/or functional) of the Development team becomes "Empirical Process Control" or "Ëmpiricism" (Empiricism asserts that knowledge comes from experience and making decisions based on what is known.). 

No, because estimates and other useful information should always be kept up-to-date, and inspection and adaptation ought to be as timely as possible. Hence there are only three artifacts in Scrum...the Product Backlog, the Sprint Backlog, and the Increment. Logs would be untimely for the purposes of empirical process control and hence are not part of the framework. 

Thanks a lot Ian. I learned a lot from this discussion.

A Scrum project is planned to have two releases, one of the middle and the other at the end of the project. What will happen?

Hopefully a Scrum Master will explain that the most important project is the Sprint, because that's the one which allows empiricism to be established and maintained. Any number of releases might be made.

Well, I would assume that there would be a release in the middle of the project and one at the end of the project.  However, I am not entirely sure what you mean by a "Scrum project", especially one that has seems to already have planned out all of the necessary iterations.  That seems more like a waterfall project that wants to use some Scrum terminology. 

In an environment that is utilizing the Scrum framework, releases can occur anytime and as seldom/often as desired.  The focus isn't on a release, but it is on the creation of one or more usable increments of value in every Sprint. My normal coaching is that each increment is of release quality and integrated with all previous increments so that an increment can be released at any time. As discussed above, because of the empirical nature of Scrum, each Sprint will also provide new information about what is and should be built into the Product. 

Now, let me turn your question around.  What do you expect will happen? Why does it only make sense to release twice? How long is this "Scrum project" expected to last?